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ABSTRACT 


This thesis examines the various mochatisns: for naming 
the information objects. stored in a general-purpose computing 
utility, and isolates a basic set of: naming facilities that must 
be protected to assure complete: control. over user interaction and 
that allow desired interactions among users: to-occur:in a natural 
way. Minimizing the protected naming: facilities consistent. with 
the functional objective of controlled, but. natural, user 
interaction contributes to defining a security kernel for a 
general-purpose computing utility, .The security kernel is that 
complex of programs that must be.¢@orrect if control on user 
interaction is to be assured... Dyed, So hee PSs 


The Multics system is used as atest case, and its 
segment naming mechanisms are redesigned to reduce the part that 


must be protected as part of the supervisor. To: show that ~this 


smaller protected. naming facility can still support the complete 
functionality of Multics, a test impdementation of the design is 
performed. The new design is shown. to :have a significant impact 
on the size and complexity of. the Multica: pener or: 


*This report is based upon a thesis of the same title submitted 
to the Department of Electrical Engineering, Massachusetts 
Institute of Technology, on July 7, 1975 -in. partial fulfillment 
of the requirements for the degree of Master of Science. 
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This thesis investigates the class. of computing utility 
mechanisms that. deal with naming information objects within a 
computing utility. Our soni is to understand the various 
functions played by name spaces in comtemporary computing 
utilities and to decide which of these functions must be 
protected to assure complete control over user interaction. The 
Multics system, which is a sophisticated computing utility, will 
be used to test the validity of our conclusions. (1) We will 
find that Multics protects several mechanisms that we claim need 
not be protected to assure control over. user interaction. ‘To 
substantiate our claim we will present a redesign of Multics that 
allows these mechanisms to be unprotected without sacrificing the 
ability to control user interaction. - The resulting reduction in 
the amount of code that must be protected to assure control over 
user interaction contributes to defining a security kernel for 


_Multics. 


(1) The Multics system was developed as a prototype computing 
utility by Honeywell Information Systems, Ine.,° and M.I.T.'s 
Project MAC. A complete bibliography of the Multic system may 
be found in [M2]. 


ne 


1.2 Related Work 


The Multics system [C1, C2, M2, 01, S3] is an example 
of a sophisticated state-of-the-art computing utility. As part 
of a general investigation into how one goes about the task of 
certifying the security of large systems, the Computer Systems 
Research Division of Project MAC at M.I.T. is attempting to 
produce a certifiably secure version of the Multics system, by 
redesigning Multics to minimize the collection of programs that 
must be eorrect to assure complete control over user 
interactions. AS a result, this collection of programs, the 
Multics security kernel, has been steadily decreasing in size and 
complexity. & recent masters thesis {J1]} describes how a Multics 
security kernel that does not includé a dynamic linking mechanism 
was developed. This thesis Seusiwtne results of another effort 


to reduce the size of the Multics security kernel. 


1.3 Background 


A computing utility is any computer system, or network 
of interconnected computing systems, that provide general 
computing services to a community of users, Among the most 
important services provided by semaurcihe utilities are facilities 
that allow users to share, store, retrieve, and process 
information. To facilitate the manipulation and sharing of 


stored information, computing utilities must support a multitude 
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of name spaces. These name spaces,. which maintain a 
correspondence between a collection of names and the information 
they denote, provide organization of the collections of 


information processed in the system. 


We find many name spaces at all levels: of a computing 
utility. The base computers on whieh a. computing utility runs 
implicitly employ a name space that maps a set: of integer names 
(actually a set of representations. of integers). called addresses. 
into a set of words of computer memory. Similerly;, direct access 
mass storage devices such as magnetic disks: ahd drums define a 

name space that maps physical storage: addresses into: records of 
bits. At a higher. level, most compuber-utiliddes support. a name 
space that allows its users to denote files of. information by: 
character string names such as "John's_file". Detailed analysis. 


of most systems reveals many.other examples. of: name spaces. 


We have stated. that a computing .utility provides 
information processing. .services to a: community;of users. Since 
we have not placed any restrictions. upon the eomposition:of this 
user community, .we must assume that these users harbor ill will 
toward each other or toward the computing utility itself. oThis. 
ill will can manifest itself in any of three ways. A malicious 
user might attempt to use, modify, or prevent others from using 
or modifying information -in the computing utitity. Evén in a 


computing utility shared by a non-malicious user. community, one 
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user might accidently compromise another user's information or 


computation. 


Any general computing utility must prevent such 
undesirable interactions between its users. To this end it must 
secure its users against unauthorjged use, modification, or 
denial of use of the information they process in the computing 
utility. This requires that the computing utility implement an 
authorization mechanism that allows those user-information 
interactions that are to be. permitted to be specified. The 
information supplied to- the. eystem through this authorization 
mechanism must then be used by an access control mechanism that 
intercepts all user-informatieon interactions and verifies that 


they are authorized. 


The presence of access authorization and control 
mechanisms in a computing utility does not prima facie secure its 
users from harmful, uncontrolled interactions with other users of 
the computing utility. It must be established that these 
protection mechanisms do indeed perform their intended task 
without error. It further must be established that these 
information protection mechanisms cannot be subverted, damaged, 
or -cireumvented. . Only then may users of the computing utility 
process sensitive, irreplaceable, .or timely information with 


reasonable freedom from fear for its security. 
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We identify that subset of the mechanisms of a 
computing utility which must be correct in- order to guarantee 
the security of the information contained ‘in. the computing: 


utility as its security kernel, 


Clearly the task of establishing the correctness of the 
security kernel of a computing utility. must increase 
monotonically with its size and ‘complexity. For this reason it 
would be advantageous to know which computing utility mechanisms 
need be included in the security kernel for intrinsic reasons. A 
mechanism has an intrinsic need to be ineluded in the security 
kernel of a computing system if and only if it can be used by one 
computation to influence another . computation. . The access 
authorization and control mechanisms of a computing utility are 
the two most obvious examples of mechanisms that must be included 
in a security kernel. If a computing utility supports a shared 
name space for identifying stored information, then this 
mechanism, by virtue of its commonality, also allows one 
computation to influence another and henee must be considered 


part of the security kernel of the computing utility; 


Mechanisms that have no intrinsic need to be protected 
often are included in the security kernel of a system. Common 
reasons for incorporating a mechanism.in the seourity kernel of a 
computing utility when it has no intrinsic: need to be- protected 


include the desire to protect the mechanism from damage, the 
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desire to minimize cross domain Cails, and the need to protect 
the mechanism Gecause some: secarity kerset mechanism happens to 
depend upon its eorrect« operation: “The motivation behind 
including a mechanism in the seéerity “kermel of a computing 
utility when ft has no security-related need: to be protected must 
be carefully analyzed; as the in¢clasion of the mechanism in the 
security kernel contributes to the complexity of the security 
kernel. Removing the mechanism :from the. seourity kerrel would 
have the advantage -of lessening’ the task ‘of establishing the 
correctness-of the security kernel. .This thesis will ‘evaluate 
the need for each of the major name spades supported by a typical 
computing utility to be ineluded “in fitssécurity kernel. We will 
use the kndwledge : thus accumulated to ‘simplify the Multic¢s 


security kernel: — if eR ee ee 
1.4 Plan of thesis: 


‘In Chapter II we: present. a model. of a computing 
utility, This:moedel pays partieular:‘attention to those 
mechanisms that are involved in naming-information: stored in a 
computing utility. We begin ° by defining a very simple 
information storage and protection model. Through successive 
enhancement of this model we arrive at.a model that we feel 
represents the.éessenee of name space management tn a contemporary 
computing utility. As we add each new tind: space to our model, 


we consider its: basic raison -d'étre, the advantages and 
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disadvantages it provides over the previous model, and most 
importantly its impact upon which name spaces in the model must 


be protected as a part of the security kernel. 


Chapter III begins our case study of ‘name space 
management in Multies. We identify thé major name spaces 
maintained by Multics that, deal with naming stored information 
and establish a correspondencé ‘between these namé spaces and the 
name spaces of our: model. Having ~estabtished - this 
correspondence, we attempt to varity” that’ only the naming 
functions identified in our model as ‘sécurfty sensitive are 
implemented by ‘the Multies security kernei. ‘This investigation 
reveals that the Multics reference name spate, a fame space used 
in resolving inter-procedure references; is implemented in the 
Multics security kernel although it has ro intrinsic need to be 
protected. (1) The reasons behind thts flaw‘in the modularity of 


the Multics system are investigated. — 


In Chapter IV we develop a design that removes 
reference name management from the security kernel of the Multics | 
system. In so doing, we also remove several’ functions related — 
to the management of the Multics global naming hierarchy from the 
Multics security kernel. The most notable of these ae that 


function which allows the security kernel to name segments by 


(1) The research reported in this thesis is based upon the M.I.T. 
Multics system of December 1974, Multics system 24.2. 
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hierarchy pathnames and that. funetion which allows multiple 
paths in the Multics storage system, sierarghy to designate the 
same object. In the course of removing these functions from the 
security kernel, our design drastically changes the Multics 
security kernel interface... Finally,.we, discuss .the..impact of 


this design upon. the security kernel... 


Chapter. V discusses the Jmplications of our security 
kernel design upon code running outaide of.the Multies security 
kernel. We discuss. the-.pringiples. involved in.designing a 
reference name manager which runs: outside of the -Multies security 
Kernel. In the course of. this. presentation. we... uneover an 
important "consideration. in moving. any module out of the Multics 
security kernel. Specifically, ..Mgities security kernel 
procedures are guaranteed {o. run...to completion once invoked. — 
This allows them to make assumptions that. would be invalid were 
they to be executed in the interuptable environment: outside of 
the security kernel. Following this discussion, we show how the 
functions of pathname resolution, apd . storage «system link 
processing may be implemented outside of. the Multiecs security 
kernel. Finally, we .discuss,the. need for simulating the old 


security kernel interface.. 
In Chapter VI we. discuss. the. .results of a test 


implementation of the security kernel we have designed. This 


test implementation allowed us to iteasure of the impact of our 
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design upon the complexity and performance of the Multics system. 
We report this data along with a> description of our test 


implementation. 


We have included nine appendices in this thesis. 
Appendix A details the structure of the data base°for the Multics. 
24.2 address space manager and referen¢e name manager. Appendix 
B. shows the impact of our design upon the structure and content 
of this data base. Appendix C summarizes the new address space 
manager interface proposed in this thesis. In appendix D we 
present an example of the use of this new interface. Appendix £ 
summarizes the impact of this thesis upon the size of the Multics 
security kernel. In appendix F we report ‘the details and results 
of our performance comparison between Multics system 24.2 and our 
test system.. Appendix G summarizes the effect of our thesis upon 
the complexity of the Multics security kernel interface. 
Appendix H presents the programs of our redesigned address space 
manager for the reader's perusal. Appendix I discusses several 
functions supported by the Multies. system.24.2 “address space 
Manager that, for the sake of simplicity, were not considered in 


the body of the thesis. 
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In this chapter we will develop a model of a computing 
utility. Our emphasis will be -upon the roles played by name 
spaces in. contemporary computing utilities. This model will be 
developed by adding successive layers to .a. central model of 
information storage and protection. After we add each successive 
mechanism or name space to this model, we will present.a graphic 
representation of the current state of the model. Each node in 
these illustrations will represent a Glass of (names. The name 
space binding one group of names to another group of objects or 
names will be represented by an undirected line. If a name space 
must be protected to control user interaction, then the line 
representing it will be constructed from the symbol "+". If the 
name space need not be protected it will be represented by-.a line 


composed of the symbol "."., 


Some basic notion of information storage and. protection 
must be at the heart of any computing utility model. In our 
model the basic vessel of information storage is a segment. In 


theory, we do not restrict the amount of information a segment 
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may contain. In practice, the amount of information a segment 
may hold will be bounded by a combination of hardware and 


software limitations. 


Segments will also serve as our basic unit of 
information protection. | We require’: that any information 
protection must apply uniformly to all information stored within 
a segment. We will choose an access’ contol 148t “(ACL) based 
information. protection ‘stheme “for our -modét; The basic 
motivation behind this choice is that -Multics. ‘our ‘test ‘case 
system, uses.an access control list ‘protection: scheme. — 

We. assume that an access ‘control list is associated 
with every segment... This access control ‘list encodes the 
authority of each principal in the computing utility to use or 
modify the contents of the associated segment. (1) We will 
further assume that the computing utility supports the necessary 
principal authentication and access autWorfization mechanisms for 
maintaining the contents of access control lists. We require 
that at some point in referencing any segment, its associated 


access control list be used to méd#ate’ that ‘reference. 


(1) We assume that the reader is familiar with such computer 
science concepts as access, pepays erin domains, processes, and 
principals [S4, F1]. : | 


me es 


We will name a segment and its aecesas control list by a 
name that is unique within the system. This name, which we will 
call a unique identifier (UID), will be compaet, fixed length, 
and of high informetion density.,.-The. unique identifier naming. a 
segment and its access contre]. iiet will be assigned when the 
segment is ereated and may never. be: changed: © Once assigned, a 
unique identifier will be Valid-fer-all time. If we allowed a 
unique identifier to be reused after the segment it names is 
destroyed, then ‘that identifier wauld not-uniguely identify a 
segment. It would be difficult, if not impossible, for a process | 
to distinguish between different segmente, existing. at. mutually 
exclusive points in time, named by the same unique identifier. 
(1) 


It ahould be noted that we have purposely excluded the 
possibility of having more than one unique tdentifier bound to 
the same object. The reason for this.is the need to determine if 
two segments are identical. if we guarantee that no two unique 
identifiers are bound to. the same: objest, then we can decide if 
two segments are identical by comparing their unique identifiers. 
Lacking this guarantee, it is not. clear how a process could 


decide if two segments were the same segment. (2) 


(1) A discussion of the need for computing systems to ‘support 
unique identifier name spaces. may be found: in: eaEy [F1). 


(2) By equal we mean the lisp concept of eq [Ma], 
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Due to their compact size, unique identifiers are well 
suited to efficient implementation: and manipulation by computing 
hardware. We will assume, for the moment, that access control 
will operate during the translation of unique identifier to 
object. Certainly this requires. that the -name spaces that 
associate unique identifiers with objects and their associated 
access control lists be protected. ‘Otherwise: a ‘process could 
circumvent the access control mechanisms of ‘the ‘system by causing 
the unique identifier associated with any ségment to name an 
arbitrary access control list or equivalently, ‘causing the unique 
identifier associated with any access control list to name an 
arbitrary segment. It is therefore necessary: ‘that the security 
kernel exercise complete control over the unique. identifier to 
access control list and unique identifier to segment name spaces. 
Since the security. kernel must force these ‘two name ‘spaces to 
correspond, we will treat them as a single . entity. Figure 2=1 
illustrates this protected binding mapping unique identifiers 


into segments and their access control lists. 


<UID> +++ <SEG/ACL> 


Figure 2-1: Global Machine-Oriented Names 


2.3 Global User Oriented Names 


From the point of view of a human user, the unique 


identifier name space which we have defined for naming segments 
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has four major inherent disadvantages. The first disadvantage is 
that humans are poor at dealing with nigh information density 
names. Second, since unique identifiers must be assigned by the 
system and not the user, they can have no mnesonic significance. 
Third, the binding or meaning of a unique identifier cannot be 
changed. The final disadvantage in. the usage of unique 
identifiers by humans is that it is often convenient to allow 
multiple names in a name space to denote the same object. In our 
model we have precluded the possibility of -having two unique 


identifiers name the same segment. 


For these reasons, any viable computing utility must 
support a user-oriented name space. Ideally this name space 
should bind arbitrary length, useresupplied character string 
names to unique identifiers. In practice, some upper bound is 
often placed upon the size of user-supplied names. In any 
reasonable computing utility this restriction must not force 
users to use difficult-to-remember non-mnemonic names. To 
promote and encourage information sharing, this name space 
should be sharable by all processes in the computing utility. If 
this were not the case, then one user who wished to share a 
segment with another user would have to ébamadhicate the unique 
identifier of that segment to the other user. A shared 
user-oriented name space eases this -@ommundecation problem by 
allowing users to identify segments in interpersonal 


communication by human-oriented names. 
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A well known weakness of such a: simpke, unstructured, 


global name space, which results from ‘the need for a name space . 


to define a function, is that two users may not name different 


Segments by the same name. If’ One user names a segment 


"Square_root_program", then no other user may. ‘use this name for 


another segment. Perhaps the most severe manifestation of this 
problem is that a user may not choose a name for a segment 


without knowledge of.every name in.the global: name space. — 


Another consequence . of the. global scope of the name 
Space we are defining. is that it provides a path of user 
interaction. One user ‘might. intentionally “modify a name to 
unique identifier binding that another user was® depending upon, 


This constitutes an uncontrolled malicious. usef interaction since 


it allows one. process to cause another process to reference the 


wrong segment. This in turn may cause an unsuspecting process to 
fail or compromise the integrity. or security of sensitive 
information to which it has icoeen: It is*therefore apparent 
that the ability to. change a gicbalvdsercorheweed name space must 


be regulated by the security kernel. 


One simple avtnorisaticn scheme a computing utility 
could adopt for its global user-oriented name space is to allow 
only the principal who created a name binding to modify that 
binding. Unfortunately, even sien a primitive authorization 
mechanism is an unwieldy extension to the unstructured name space 


we have defined. Such an extension would require that every name 
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binding in the name space have an associated principal name used 
to authorize modifications of that name binding. If the name 
Space were structured into meawtngfwil dollections of name 
bindings, then a more natural authorization scheme based on 
controlling a preeess' abdtlity to modify. any of a related 


collection of name bindings could be employed. 


Hierarchical name spaces, such as the user-oriented 
name spaces found in the Multies [B1, O01] and UNIX [R2] 
time-sharing systems, provide a powerful and natural solution to 
both the naming cenflict and autherization: problems outlined 
above. Since most name spaces fourd in contemporary computer 
systems, such as the ubiquitous "two-level" f22é system [M3], may 
be described as degenerate fixed«depth Aterarchies, our model 


will support a hierarchical global weersoriented name space. 


Hierarchical name spaces provide tteir users with a 
powerful organizational mechanism, This mechanism encourages 
logically related name bindings to bé deéllected in a single 
directory or directory sub-tree of the hierarchical name space. 
For instance, each user could place name bindings he creates in 
distinct sub«trees of the hierarchy. Naming conflicts within a 
given directory are easily avoided by locally restructuring the 
hierarchical name space so that the conflicting name bindings 
occur in different directories: The directory structure of a 


hierarchical name space can also serve as the basis for a simple, 
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flexible mechanism for controlling the modification of the name 
bindings in the hierarchical mame space. The ability to use 
and/or change the name bindings in a directory can’ be specified 
by an access control list on that directory. Authorization 
control may also be delegated by allowing the access control 
lists of a directory to specify which principal may modify the 
access control lists of its: sub-directories. Figure 2-2 extends 
our model to include both human-oriented and. machine-oriented 
global name spaces, . 
USER ORIENTED MACHINE ORIENTED 
NAMES NAMES 
<PATHNAME> 4444444444444 <UID> 4444+ <SEG/ACL> 


Figure 2-2: Global User-Oriented Names 


2.4 Local Machine Qriented Names 


At this point our: model provides two very powerful 
mechanisms for naming information. One mechanism allows any 
segment in a computing utility to be denoted by a compact, 
fixed-length, unique identifier. | The other naming mechanism 
allows segments to be named by arbitrary length character String 
names indicating the position of a segment in a naming hierarchy. 
In common to both of these mechanisms is the fact that their 
scope is global; they are shared by all users of the computing. 
utility. | 
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An. obvious implication of the scope of a unique 
identifier is that it must be capable oF representing as many 
distinct segments as the computing utility could create 
throughout its entire life. Because the set of segments existing 
at any one time wilkl be a small subset of all segments that have 
ever existed or will ever exist, our unique identifier name space 
will be spargely populated. For Large aystems with long 
lifetimes, this unique identifier name space will also be quite 
large. Economics demand that such large, sparse mappings be 
stored in a compact form requiring mare sophisticated accessing 
methods than indexing by unique identifier value. This need for 
sophisticated retrieval methods in conjunction..with the large 
potential size of the unique identifier to segment mapping tables 
suggests that this name space ig difficult .te implement 
efficiently. As a result, contemporary computing hardware 
provides a name space for addressing segments that is much 
smaller and denser than the global. unique identifier name “speees 
The increased efficiency of representation and mapping of this 
name space is achieved by ‘restricting the ‘scope of the 


machine-oriented segment identifiers. 


The local | machine-oriented name space in our model is 
patterned after the Multics segment number name space. Like 
unique identifiers, segment numbers are doapack. fixed-length, 
machine-oriented names. Unlike ‘unique identifiers, velabively 


few segment numbers are - supported (1) and segment numbers are 
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locally dense so that simple, efficient hardware translation 
techniques can be used. Since segments will be identified to the 
base level of the computing utility by segment number, we will 


call a segment number name space an address space. 


There are many possible choioes Por" the scope of 
segment numbers. A cooperating eolleetion of processes could 
_ share a common segment number address. space. > Segment numbers 
could be private to a process, shared by ali domains in that 
process. Conversely, the scope of a segment number could be a 
domain. It is even possible to imagine a ‘system in which the 
scope of a segment number is temporally restricted. The choice 
of which of these or other possible schémes for limiting the 
scope of segment numbers is appropriate for a given computing 
utility depends upon both the hardware on which it gust run and 
the desired patterns of interaction within the computing utility. 
The larger we allow the scope of a name spacé to be, the greater 
the cost of translating names in that name space. Conversely, 
the smaller we make the scope of a name space, ‘the fewer the 


naming needs it can satisfy, 


If we desire inter-domain communication to be 
efficient, then it would be inappropriate to restrict the scope 


of segment numbers to a domain. Were this done, segments could 


(1) Multies supports a local, machine-oriented name space of 
about four thousand segment numbers. | - 
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only be named in inter«domain communication by unique identifier 
or, worse still, pathname. Since these names are not directly 
usable by the base level hardware of the cemputing utility, they 
would have to be mapped by the receiving domain into its segment 

number address space before the segment named could be 
-referenced. By similar reasoning, if. inter«process comttunication 
oceurs with high frequency in a partiouler computing utility then 
that computing utility might... choose.te share a segment number 


address space among.a group of cooperating. processes. 


The choice of the scope of segment numbers represents 
an engineering trade-off. We must limit the scope of segment 
numbers so that they may be efficiently 4mpkemented in hardware. 
Additionally, the smaller the scope of a segment number the less 
its need to be protected. If an address - space is lecal to a 
protection domain, then it may be freely manipulated by that — 
domain without compromising security. .In opposition to the: 
efficiency considerations that weigh in favor of reducing the> 
scope of segment numbers is the desire to iaieas > tite scope of a 
segment number as large as possible so as to make communication 
between different computer systems, processes, domains, and 
moments in time as efficient..as possible. The desired 
characteristics and resources available to each computing utility 
must be carefully evaluated to determine the largest group of 
interacting objects that can share an address space without 


making the address space unacceptably large. 
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Routine communication between the... security kernel 
domain and other protection ona ine in a computing utility should 
probably, for performance and modular programming reasons, be 
performed by using segment numbers to..denote segments. This 
requires that the ability to manipulate the segment number name 
Space we have just defined be controlled: by the security kernel, 
This need for the security kernel. to control: the manipulation of 
an address space would not arise if address spaces did not span 
protection domains. The reader should take note of the fact that 
since segment numbers do not have global scope, our global 
user-oriented name space cannot be implemented: by binding names 
to segment. numbers... Figure 2-3 extends. our model to inelude the’ 
protected binding of segment numbers to segments: and their access 
control lists. We also include. a. protected. binding between 
segment numbers and unique identifiers. This. binding allows the 


identity of a segment named. by a segment. number to be 


established. 
‘USER ORIENTED | MACHINE ORIENTED 
NAMES .. ds dl 28 NAMES .~ 

PER~SYSTEM | <PATHNAME> ¢4+4++¢4¢¢+ <UID> +44 <SEG/ACL> 

+ + 

aa. $2 

PER-~ADDRESS SPACE <SEGNO> 
Figure 2-3: Local Machine-Oriented Names 
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Economics require that we refine the segment number to 
aceess control list and segment translations depicted by our 
model. These trenelations must be perforhed wpoh every reference 
to a segment. it is thus essential that they be efficiently 
implemented. In light of current computing technology, these 
translations must be performed ih hardware if we desire our 


computing utility to be economically feasible, 


Contemporary computing hardware supports neither the 
ability to address arbitrary amounts of. storage nor the ability 
to perform the necessary access control 118t search upon every 
reference to a segment. To solve these prebliems one frequently 
finds two high=speed, hardware look«aside memories aiding the 
processors that implement a computing utility. One associative 
memory maps a segment number and domain identifier into a 
hardware interpretable representation of the domain's access to 
the segment specified sy that segment unter: We will call the 
entries in this associative memory protectiog descriptors (PDS). 
The other associative memory maps a segment — number into an 
addressing descriptor (ADS) that allows the napduane Vo address 


the representation of a segment. 


The processors we have described look up the address of 


a segment in their addressing descriptor associative memory and 
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validate their authority to reference the segment with respect to 
the appropriate protection descriptor found in their protection 
descriptor associative memory. When one of these descriptors is 
not found in its associative memory, a hardware fault will be 
recognized. At this point software may intervene and take the 
appropriate steps to load the necessary descriptors and restart 


the faulted program. 


Clearly the security kernel. must control the 
manipulation of the protection descriptor and addressing 
descriptor name spaces. This is necessary since there exists a 
one-to-one correspondence between addressing descriptors and 
protection descriptors which must be maintained to preserve the 
integrity of the system's access control mechanisms. Figure 2-4 
refines our previous model by supplanting the protected segment 
number to segment and access control list mapping by the four 


protected mappings described above. 


USER ORIENTED MACHINE ORIENTED 


NAMES ‘NAMES 
PER-SYSTEM <PATHNAME> +444++ <UID> +#++444+ <SEG/ACL> 
+ + + 
+: = + + 
PER-ADDRESS SPACE <SEGNO> + <ADS> + + 
+ + 
+ + 
PER-DOMAIN <PDS> +4 444+44+4+444+4+44 


Figure 2-4: Local Descriptors 
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We have geen that efficiency considerations require our 
model to support a limited~seope, machiné-ortented name space. 
It is only natural to consider whether there would be any 
advantages in our model also swpporting 2 user-oriented name 


Space of limited scope. The answer is, quite emphatically, yes. 


Like the segment number name space we have defined, a 
user-oriented name space of lodgal scope would be easier and 
faster to search than its global couriterpart. But more 
important, it would provide a@ private nase space that could be 
manipulated arbitrarily without worrying about interactions with 
processes outside of the scope of the name space. This latter 


ability is necessary in providing modular programming facilities. 


It is clear that a program should not code into itself 
the unique identifier or even the pathname of another program, 
such as a Square root program, that it wishes to call. This 
premature binding between modules would require that the first 
program be changed and recompiled if a new and better square root 
program was added to the. computing utility. The caller of a 
square root program does not, in general, wish to be bound to a 
particular square root program. If the choice of which routine a 
procedure is to call can be delayed until the Gall is made, then 


we gain much flexibility. 


~30- 


We call a name that one program).uses to refer to 
another program a reference name [01] 1f-its meaning is only 
defined in relation to a local. name space. Sueh a local 
user-oriented name space is called a reference name space. One 
way to implement a space of reference names is to maintain a list 
of reference name to segment associations [01). Another 
mechanism for realizing a reference name space, found in many 
contemporary computer systems tJ1; I1], involves searching an 
ordered list of specified directories, called search rules, to 
resolve inter-program references. ‘Reference names provide a very 
useful mechanism for combining separately Souneived subsystems 
and testing new subsystems all of whose components have yet to be 
written by allowing reference name to seanent binding to be 
defered until the components of a subsystem. are combined for 


execution. 


In our model, each domain will have a private reference 
name space. This minimizes the problem of naming gonfiiets and 
allows each protection domain to operate without regard to the 
reference names used in other domains. A further advantage of | 
per-domain reference names is that they need not “ explicitly 
protected or controlled by the spurte: Kernel: Since reference 
names are private to a protection domain, each domain may freely 
manipulate its own reference name space. All that.is required is 
that the reference names of each protection domain be stored ina 
segment accessible to only that protection domain. If reference 


names spanned protection domains, it would be necessary for a 
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security kernel mechanism to control the manipulation of 
reference names to prevent one domain from exerting uncontrolled 
influence over another domain through the manipulation of 
reference names. Figure 2-5 shows the relationship of the 
unprotected reference name space to the other name spaces 


deseribed so far. 


USER ORIENTED MACHINE ORIENTED 


NAMES NAMES 
PER=-SYSTEM <PATHMAME> +4+44+4+4 <UID> 4444444 <“SEG/ACL> 
+ + + 
* ae + 
PER~ADDRESS SPACE <SEGNO> + <ADS> + + 
i Z -- re + 
: + + 
PER-DOMAIN <REFERENCE NAME> .. ++ <PDS> +4+4+++4++++ 


Figure 2-5: Lo¢al User-Oriented Names 


2.7 Summary 


In this shapter we have investigated the basic roles 
. played by name spaces ina typical computing utility. Of the 
eight name spaces we have described, only the per-domain— 
reference name space bay be excluded from the security kernel 
without jeopardizing the ability of the computing utility to 
control user interactions. The critical difference between the 
reference name space, which can be uncontrolled, and the other 


seven name spaces we have considered, which must be controlled, — 


“32 


is that the reference name space is not common to multiple 
protection environments. Since it cannot be used by one 
protection domain to exert influence over another’ protection 


domain, it need not be implemented in the security kernel. 
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Before approaching the specific problem of defining a 
security kernel for the Multics system that does not support 
unnecessary name space management mechanisms, we will present a 
detailed model of the Multics system and show its correspondence 
with our general computing utility model. Our Multics model 
contains four components: a storage system model, an information 
protection model, an address space model, and a reference name 
model. These models will contain sufficient detail to allow the 
reader who is unfamiliar with the implementation of Multics to 


comprehend the important details of the design we will present. 


3.1 Storage System Model 


The Multics storage system (1) manages two distinctly 
different types of objects called segments -and directories. 
These objects are organized into a single system-wide tree 
structure that is known as the storage system hierarchy. This 
hierarchy implements the system's  human-oriented global name 
space. The internal nodes of this hierarchy are directory 
objects. Each directory object is itself Semposed’” of a named 


rer ep frase srry refs sree 


(1) A more complete description of the Multics storage system 
than will be presented in this section may be found in Organick 
[01] and Bensoussan [B1]. 
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collection of entries, one for each inmediately inferior segment 
or directory in the hierarchy and one ‘for’ each link in ‘the 
directory. Links are psuedo-objects in the hierarchy that allow 
an object £S\/appaar to reside at several distinct nodes in the 
hierarchy. To accomplish this, the directory entry of a link 
contains the pathname of another object: or Yink in the hierarchy 
that is to be considered as the target object of the link. The 
directory entry of a segment or directory object contains many 
important attributes of the object. Among these attributes are: 
a system-wide unique identifier, a collection of ‘human-readable 
names for the ob ject that are unique Within the directory, an 
access control list, and a file map for the “object that allows 


the system to access: the object. 


Each directory in the Multics hierarchy is stored ina 


separate segment. Many. advantages | accrue | fPom supporting a 
hierarchical name space whose directories are implemented in 
separate segments. These advantages are ciosely interrelated. 
First, since each directory contains oniy a small fraction of the 
total. name bindings represented by the hierarchy, it may be 
searched much more quickly than a corresponding’ single ‘segment 
implementation of the whole’ hierarchy. ‘Finding a name in a 
hierarchically organized name space requires searching only those 
directories defined by the prefixes of the name. ‘In ‘general, 
this will represent a substantial “savings ‘in’ search ‘time. 


Second, the component naémes in a directory may be viewed as’ 
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uniform, unstructured names. Finally, the names in a directory 


can be relatively small and yet still be unique. 


As we have mentioned, a practical. computing utility 
cannot assume that all users will be benevalent with respect to 
their manipulation of a global, shared aame space. We must 
assume that abiea Nines through malice or aqcident, will attempt. 
to delete or modify name bindings that other users are depending 
upon. If this glohal name space is to be useful, then users must. 
be able to control or at least. know wha may change the name 
bindings that are of interest to them. ‘Controlling who may read 
the name bindings in a partioular: dirantery of a shared name 


space is also desirable since the names in oa. directory might 


themselves constitute sensitive information. 


Since segments are the basic unit of access control in 
Multics, it is only natural to control the. manipulation. of the 
names in a directory. by the Multies segment access control 
mechanisms. This approach.is quite attraetive since it allows 
the name bindings in a name space to be.protected without 
introducing any new, special purpose access. control mechanisms. 
The access control list of a directory specifies which principals 
may read and write its representation. In thia- way, the normal 
access control and authorization .meghanisns of Multics 
automatically provide a certain degree of control over the 


manipulation of names in its hierarchical name space. Multics 
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actually provides finer access eontrol on directories than is 
afforded by its hardware enforced access control mechanism by 
encapsulating directories and a set of system-supplied procedures 
which manipulate directories in a protected subsystem [S1]. The 
procedures in this protected subsystem, which must be a part of 
the security kernel, exercise control over the use and 


manipulation of the name bindings in a directory. 


If we assume that the root directory of the hierarchy 
is its own parent, then every object in the Multics storage 
system has a unique parent directory. Furthermore, since the 
hierarchy has the structure of a tree and names of directory 
entries are unique within that directory, we can specify an 
arbitrary object in the hierarchy by an ordered list of entry 
names. Such a specification is called a pathname. The first 
component of a pathname names an entry within the root directory, 
and each additional name specifies an entry within the directory 
specified by the list of names that preceeded it. By convention 
we take the name of the root to be thie auld nana, and we write 


the pathname a, b, ... q aS >a>b>...>q. 


A leaf node of the Multics hierarchy can be either an 
empty directory, a link, ora segment. Segment objects, which 
are implemented directly by the Multies hardware, are primitive 


objects in which programs and data are stored. 
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In our general computing utility model a directory 
entry consists of one name to unique identifier mapping stored in 
a directory of thé user-oriented hierarchidal name space. The 
issue of where to store the a¢cess control ltst and other 
attributes of @ Ségment of dirédtory, which was not addressed by 
our general model, was resolved in Multics by merging this 
information with the entries of its hierarchical name space. 
This scheme has three important consequences. First, because a 
directory entry contains the attributes of the segment it names, 
no two directory entries in the hierarchy are allowed to describe 
the same segment. (1) This requires that an entry contain all 
synonyms of the object it describes. In ‘our general computing 
utility model this was not necessary since there was no penality 
associated with allowing multiple entries (single name to unique 


identifier mappings) to denote the same object. 


Second, the unique identifier to segment name space of 
our general computing utility model exists in Multics only as a 
collection of individual mappings scattered throughout all 
directory segments in the hierarchy. This renders the task of 
locating a segment given its unique identifier prohibitively 
expensive, However, Multics does wusé unique identifiers. to 
facilitate the determination of whether two objects denoted by 
different pathnames are in fact the same object. 


(1) If this rule were not obeyed, then the system would be faced 
with the error-prone task of maintaining identical, but separate, 
copies of the attributes of a segment. 
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Third, because the access control list of an object is 
stored in the object's superior directory, it is not possible to 
have the access control. list on’ that ob fect arbitrate access to. 
the object independent of the access control lists on the 
object's superior directories. To see that this’ is true all we 
need do is consider the following *scenario’ of a process 
attempting to. reference a: segment*’ - Abeume that the access 
control list ofthe segment ‘specifies: that the process is 
authorized to reference the segment, but’ that the segment's 
directory entry resides in a directory® to which the process has 
no access. The system is faced with a paradox.-° If it allows the 
process to reference the segment, then it*must allow the process 
to use information in the segment*s: directory entry. But the 
process is not authorized to use information in. the directory 
containing the entry. Thus, if the system permits the process to 
reference the segment, then ft must violaté the authorization 
specified in the access control list of’ the eontaining directory. 
Conversely, if the system does not permit the process to 
reference the segment, then it must violate’ the authorization 
specified in the access control list® of “the~-segment. This 


dilemma will be discussed in detail in the fiext chapter. 
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The active agent of. .computation:: in Mudtics is a 
process. A process may execute. instructions.:dn. any .of eight 
protection domains,. numbered from 0 to 7. These domains have the 
property that a process’. access rights; to objeots:in the storage 
system while executing in. domain n.are a subset of its access 
rights while executing. in domain net. «Domains that are so 
constrained have been named rings {S2].° To identify the user on 
whose behalf a. process. is executing inatructions, the system 
associates with. each process: an unforgeabie principal name. This 
access control. name is used to establish a. process' rights to 


access directories: and. segments. in. the storage..system hierarchy. 


Associated with each..segment. and .directory in the 
storage system hierarchy is an aoress control list which, in 
conjunction with the access control name.and ring of execution of 
a-process, completely determines. the. access rights of that 
process to the object. The access control list in the directory 
entry of an object .-encades . the, .accegs mede or rights each 
principal is to.have to . the -asociated. @bject ina given 


protection ring. (1) 


(1) In the current Multics implementation both a segment's access 
control list and its ring brackets. must be considered to 
determine the access rights of a principal to the segment ina 
given ring. Since this level of detail is unimportant for our 
purposes, we will imagine that a segment's access control list 
alone is sufficient to determine access. 
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When a process attempts to reference a segment or 
directory, the system evaluates the process’ access modes to the. 
target object. Conceptually, this involves searching the access 
control list of the Sb jaces This information is used to validate 
the process! right to perform a given operation upon the segment 
or directory. In the case. of evaluating access to segments, 
Multics relies upon the hardware associative memories described 


in our general model to make access validation efficient. 


For segments the valid sodeak modés are read, write, 
and execute, These access modes are enforced directly by the 
Multics hardware. The.valid access modes for directories are 
Status - the right to read the attributes of the: entries in the 
directory; modify - the right to change the attributes of the 
entries in the directory; and append’ = the right to add new. 
entries to the directory. Directory access modes are 


interpretively enforced by the Muiticos security kernel. 


Links, which are not full fledged objects in the 
Multics hierarchy, are not given san saecéess: control list. 
Instead, access to read the contents of a link is granted to any 
process that has status permission to the “link's containing. 


directory. 
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The process of a. narmal user. executes in protection 
ring four. This allows the process..ta access only those segments 
and directories.to which it has nan-nyll aoceass in ring four or 
some higher. numbaned ring. . In order to access a storage system 
object aqoessible to the progess anly..in- rings -numbered lower 
than. four, a user. process must..enter an appropriate lower ring. 
This may be done only by calling a procedure which is designated, 
by its access control list, as a gate into that ring. When such 
a gate procedure is called, the process enters the inner ring. 
By virtue of its having entered. an inner ring, the access rights 
of the procesa may increase. When the process returns from the 
gate procedure, it reenters its previous ring of -execution and ~ 
relinquishes the access rights it gained on entry to the lower — 
ring. To put teeth into this protection meohanism, the storage 
system manager will not allow a. process to create a gate into a 
- lower ring, than the ring the. process is currently executing in. 
This insures .that only. procedures authorized-to-run in an inner 


ring may create gates into that ring. (1) 


The Multics system takes ‘advantage of this ring 
protection mechanism to protect its security kernel programs and 
data bases from tampering by nonskernel prdéédures. This is 
accomplished by. setting the access control lists of security 


kernel procedures and data bases to indicate that they may be 


(1) More complete descriptions of the Multics protection 
mechanisms may be found in Saltzer [83], Sehroeder [S82], and 
Organick [01]. 
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accessed only by processes executing in protection ring zero. 
Entry points in the security kernel which- are callable by 


non-kernel procedures are declared to be gates -into ring zero. 
3-3 Address Space Model 


The Multics system associates an address Space with: 
each process [B1]. The function served by this address space is 
to provide a auppine from a .small] set of virtual addresses, 
called segment numbers, that can be direetly:° translated “by the 
Multics hardware, .onto the. mueh larger set.of objects in the 
Multics hierarchy. This segment number. address space corresponds — 
to the local machine-oriented name. apace-defined in our general 
computing utility model. In the Multics system. every process has 


a potential address space of several-thousand segment numbers. 


The binding of a segment.-number to a:storage system 
object, which incorporates a storage aystem object into an 
address space, is called initiation. . The effect of initiating a 
storage system objerpt is to .maké.. the representation of that 
object appear directly addressable. by. the hardware: of the Multics 
machine, Since Multics relies upon addressing and protection 
descriptors, such as those described in our. computing utility 
model, to implement hardware references: to .- segments, only a 
fraction of the hardware segment number to segment mappings 


implied by a process! address space need exist at any. given 
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instance. Az in our computing utility model, ‘the Multics 
security kernel handles faults ocatsed by attempting to use 
missing descriptors by reloading the missing addressing or 
protection descriptor and restarting the faulted process. The 
unbinding of a storage system object from a ‘segment nutrber, which 
removes the object from the process' address space, is called 


termination. 


Our discussion may have lead the reader to the 
conelusion that a process may have several segment numbers bound 
to. the same storage system object. Actually, “this is not 
permitted by the address space manager. During the initiation of 
an object, the address space manager locates the directory entry 
of the object from which it fetches the system-wide unique 
identifier of the object. This identifier is looked up in a 
per-process table (1) that maps unique identifiers into segment 
numbers, If the unique identifier is found in this table, then 
the. object is already in the address space of the process. This 
being the case, the initiation primitive returns an indication to 
this effect as well as the segment number that is bound to the : 
object. This scheme has several advantages. First, it helps a 
process conserve its segment numbers - a very scarce resource. 
Second, it permits a process to test the identity of two objects 


in its address space by comparing the segment numbers assigned to 


(1) See appendix A. 
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these objects. Finally, it simplifies the management of the 


Multics virtual memory. 


Scar “RePevendé Nema Spsee Model 


We Have, sesented. that iooal usersoriented name spaces 
in a computing utility need not be part of its security kernel. 
This claim not withstanding, the Multics supervisor implements a 
reference name space for every ring of Sueey process. These name 
spaces provide a mechanism for capping oharadter string names 
into segment numbers and vice versa. In the current Multics 
inplementacion only segments may be assigned reference names. 
The security kernel itself does not use reference names for 
normal segments. It does however misuse its unique ability to 
assign reference names to the segments with which it implements 
directory objects. (1) Specifically, the Multics supervisor uses 
the reference name manager to associate the hierarchy pathnames 
of initiated directories with the segment number of the segment 
containing the representation of bhe-dupeavory: As we will see 
in the next chapter, ‘this presents problems when directory 
objects are renamed. This problem will be discussed in great 


detail in the ensuing chapters. 


The address space manager and reference name manager 


share a common data base in the current Multics implementation. 


(1) In non-kernel domains directory objects are sealed and may 
not be accessed as segment objects. 
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This combined data base is called the Known Segment Table and is 
documented in appendix A. The reader who is unfamilar with the 
structure and contents of the KST is urged to review this 
material. Additional information on the Multics reference name 


manager may be found in Organick [01] and Bensoussan [B11]. 
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Chapter. IV 
Design . 


The Multics designers recognized the advantages of 
building a computing. utility an top of a.central security kernel.. 
As a consequence, Multics is more fortunate. than most existing 
computer systems as regards its -secqurability. By construction 
most modules of the Multics system are not permitted to. execute. 
in protection ring zero. This bulk of code .is thus prevented by 
the Multics protection mechanisms from tampering with those 
programs and data that are only accessible from. protection ring. 
zero. These protected programs constitute the Multics security 
kernel. Although the portion.of the Multics supervisor that lies 
outside of the security kernel. dwarfs. the. security kernel in 
comparison, the modules of the Multics. security kernel are . still 
quite numerous as well as complex. The object.modules of the. 
Multics security kernel. presently represent approximately one 
hundred and fifty thousand. machine instructions. These 
instructions implement in excess of. two hundred user callable 
functions as well as. a host of implicit system services such as 


demand paging. 


We will present a redesign of the current Multics 
security kernel that will enhance ita certifiability by reducing 
its size and number of external interfaces. .As.a side effect, we 


will also improve the modularity and coding of the area of the 
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system we will investigate. Our dasign will eliminate the need 
for the Multics security kernel to support reference name 
management. This requires that we carefully redesign and 
remodularize ring zero so that it ts independent of the reference 
name manager. This is necessary since:a security kernel must not 
depend upon the correctness of procedures outside of the kernel. 
Before getting into the details of our design, we will. 
investigate the reason behind ring zero's current dependenee on 


the reference name manager. 


While there does not appear to be any intrinsic need 
for the Multies security kernel to support reference name 
management, its removal from ring zero is complicated by the fact 
that the Multics address space manager uses the facilities of the 
reference name wanager to: maintain an asseriation between the. 
pathnames of directories it hes initiated in @ process and the 
segment numbers of these directories. The e@dPenS: space manager 
uses these associations to avoid having’ to repeatedly resolve 
identical directory pathnames into segment numbers. Since the 
security kernel must not depend upon a mechanism outside the 
security kernel, it is necessary to detouple the address space 
manager from the reference name taneger before the latter can be 


removed from ring zero. 
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The dependence of the address space manager upon the 


reference name manager manifests “itself in thé’*” recursive 


procedure find_ which the address space manager uses to resolve 


directory pathnames’ into “directory. segment” numbers. This 
resolution is necessary since the hardware base of the system 
only implements references to storage goetea objects by segment 
number. When find_ is invoked to’ déterside-the segment ‘number 
for a directory, it calls the reference name manager to map _ the 


pathname it is given, interpreted’as°a référente name, into a 


segment number, If the pathname is’a “reference “fame ‘known ‘in | 


ring zero of the process, “then”: find_°péttrns’the assoclated 


segment number as the segmedt humbér of the directory. (1) tf 


the pathname is: not a known ‘reference ‘name, “fhén find_ splits the 


pathname into a pathname of tte parént directéry* of the targét 


directory and the directory entry name of the target directory. 


It then calls itself _recursively..to.obtain-a -segment-- number for 


the paren directory, . ‘Using ‘this: ‘Segment iumber to refererice’ ‘the 


parent . » direskory?- “find ~ attenpts ” -“t¥itiate- th e target 


CTE eOCOnY if it sueger des. it eens vhe reference , name | manager 


to ‘bind pons pathname: ee the varget directory,” asa reference 
name, to the segment: Huster assigned to''the treet. gireptory. 


Pa 


(1). ‘As-we will see later, this ean: tease’ proviens | since * ppd 


segment .number may no! longer be’ bound’ to the ditectory® specified | 
by. followiag. the. pathname find. was given step ST. _Btep: through. . 
the directory hierarchy. 
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This thesis suggests a radical change in the ring zero 
address space..manager.. The essential reault of this change is 
that find_, as described above, need no. longer be called by ring 
zero. This allows both. find_. and. reference. name: management to be 


removed from.ring.zero... . ie .grikgadds 


One of .the.. basic. .goais..of the. Multics protection 
mechanism is that a...pnecess .should, be. unable. to detect the 
existence of .a storage system.abject.to which it has no access, 
(1) A second basic goal of the. Mubkige protect ton “mechanism is 
that the access -.control...liat. of.an-object should be ‘the sole 


specifier of access.to the object. (@) 0. us 


(1) We will consider, that . ag, @ .process -has. access. toe .the -parent 
of an object then it has sufficient access to determine the 
existence of the object. The reason for this wih. be discussed. 
later. ; 
(2) This goal was ‘not originally embodied in the Multics design. 

Originally a. process’, access. .to, an object, was: ‘funetion of three © 
different access control lists. The first list was part of the 
directory entry of. the object and ..cornespenda:. to; the access 
control list we now have. The second list was part of the 
object's parent and was common to all entries in the directory. 
The last list was a one per system master access control list. 
The result was. a very complex access evaluation mechanism that 
allowed an unwary user to increase a principal's access rights to 
an object by removing that principal from one access control list 
when his intention was actually to sent the principal access to 
the object. The complexity Of this mechanism so confused users 
that. many of them did not attempt to use: she: system: provided 
protection. mechanism, . With the ourrent:.Maltdes design a .user - 
needs only. review one. access eontrel- List: kas doteraine. who | has 
access to a ‘given’ segment. oo 


sa0S. 


These goals have made the determination ‘Of... whether a 
process. should - permitted to initjate..an arbitrary directory. 
quite difficult. This difficulty stems from the fact that the 
access control list of an object and its physical storage map 
reside in its parent. Since we wish the access control list of 
an object _to exercise complete eontrol over. access to that 
object, we must permit a process to initiate..all. superiors of 
accessible segments independent of access, to these superiors. 


But this violates our second goal. 


Multics attempts to resolve, the conflict. outlined above 
by not permitting a process. running: outgide,. of. ring .zero to 
initiate a directory. Since. a process, cannot. read the access |: 
control list of a segment until its parent is known, the system 
still must permit processes, while executing. in-ring zero, to 
initiate directories that. they may not have the. right to know 
exist. By causing the initiation of these superior directories. 
to occur ina single, indivisible ring zero call, the system 
could, in principle, prevent secunity..leaks.. Thia.could be 
accomplished by terminating those intermediate. .directories that. 
had to be initiated only to find that the process had no access. . 
to the terminal segment, before returning to the. ealler.. 
Unfortunately, Multics system 24.2 does not da.so. As a result, - 
any process can determine the existence of any postulated 
directory by attempting to initiate any,, arbitrarély: named =. 


descendent (which need not exist) of that directory and observing 
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how many segment numbers were allocated by ring zero. This is 


possible because all rings share a common address space. 


It would be felatively easy to correct the 
implementation flaw in the Multics addreis space manager pointed 
out above. Howéver, the system ‘would sti? have to be very 
careful to avoid compromising information. For’ example, “suppose 
a. process filled up its address spate intentionally and then 
called ring zero to initiate >secretsx.° YF ring zero was not. 
very careful, it might cause the process to die due to its 
inability to find an unused segment” hutrber to bihd to >secret, if 
and only if >seeret existed. This would’ allow the © existence of 
>secret to be daferred by whether or’ ot the process died. - 


The inability of a process to’ihitiate directories in 
outer rings directly has ied to ‘many needlessly  souplex 
mechanisms for manipulating directories, In addition, it has 
forced us always to refer to diréetortés” by pathname in the 
security kernel interface. ‘Not only is this inefficient, but it 
has. led to ring zéro's dependence upon find. If we could 
initiate directories directly outside rthg gero, then the ring 
zero interface could take a segment number instead of taking a 
pathname. as a. directory specifier. “Since ring zero would no 
longer need to call find_, it ‘ould mové'dut of ring zero, along 
with reference name management, without compromising the security 


of ring zero. 
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We propose allowing directories to be initiated by | 
processes executing in all rings. As was noted earlier, the 
basic problem to be solved “ts that ‘of’ deciding whether a 
process should be allowed to initiate a directory to which it has 
no explicit access. (1) There are eanchtially four schemes for 
making this decision. The first scheme involves recognizing that 
if the access control list of a: directory” is to completely 
express access. to that directory, then we must. make explicit the 
now "hidden" permission. to initiate a directory af some 
descendent of the directory is accessible to the process. The 
obvious way to accomplish this. is to invent ‘a new directory 
access mode called "initiate". “This mode would allow the named 
principal to initiate a direttory and to usé the information it 
contains that is relevent to accessing descendents of that 
directory. This makes the: decision of whether or rot a process 
should be allowed to initiate a aaPedtory quite simple. If the 
process has non-null access to the ‘directory, then it may 
initiate it. Otherwise, it may not. 


So oe ene a ete ee oe eee enna . Z ae et " ee 


(1) The reader should note that. we are ignoring, fer. the purposes. 
of this thesis, the possibility of: ‘solving ‘thé “problem outlined 
above by removing the attributes of a segment from the directory | 
hierarchy. ‘Removing the “attributes of °& segment from its parent 
directory, which may be the best long term solution, seems very 
attractive but requires a fairly extensive overhaul of the 
system. This thesis will investigate less drastic solutions to 
the directory initiation problem which do not disturb the 
structure of the Multics hierarchy. 
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This scheme does not me@t the ggai that: the access 
control list of an object completely, @gpresa:which.processes may 


access that object. While explicit initiate permission is 


probably .a. workable solution, and its....implicity.is appealing, 


adoption of such a solution would. produce a quite noticable 


change in the system's functionality. . We. choose .ta explore . 


alternative . solutions that. maintain: .the :current, system's 
funetionality., |. a es 


A way. to. maintain the current functignality of. Multics 
using explicit. , initiate... permission,.,.i8-, te,;couple:. the access 
control list on an, abject with. the. access entrok: jiste on all 


superior directories, .so:.that when a.presens is: given access to | 


an object.it.4s,also given initiate, acanss: .to:.all . superior 
directories of that. object... Whes,:a > prpeess: subsequently is 


denied access .$o,an,object, the.secyrity. kerged: must... remove . any 


initiate. permission that the. process..,had, to- the-: superior 
directories of the object. and that..resyited..s@lely from its 


having... access ta the. object. .peterminipgyowbieh initiate 


permissions..should be. remgved. .is -very.-diffieudt,. -potentialiy 


requiring that the entire directory hierarchy.be examined. 


A second way to decide whether a “process: may initiate a 


directory is to, search. the hieraroby coubtres rooted at: that — 


directory: | df the process fae noncauli aqcens to any menber - oo 


'y 
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this subtree then the process should be allowad to initiate the 
directory in question. -Naturally,. this scheme. is far -teo 


inefficient to consider seriously. 


A third’ method of “deolding” nether a process may 
initiate a directory is to require non-null. “access to the 
directory. This scheme has the GERECVRAERES: shared by the first 
scheme discussed, of preventing the access ‘control ‘dist of a 
directory or segment ‘from ‘being the ‘sole ‘arbiter. of access te 
that directory or segment. In order to fuftiate a segment, a 
process would need non-null access to the “superiors ‘oe that” 


cig re TB 
ew ko 9 


segment. 


We propose a fourth solution ‘to the problem ‘of. 
initiating directories. “Instead of worrying about. whether or not 
a process has the right to initiate a directory, let us ‘allow all 
processes to initiate any directory - “whether: ‘or not ‘it exists. 
The key to this scheme is preventing the process from detecting 
any difference between an initiated directory that does not exist 
and an initiated directory that exists but chet the ‘process has 
not proven its right to know exists. How this is to be done 
will be discussed later. | Bae eee _ 

The ring zero address space manager ‘interface resulting 
from this approach ‘seems quite natural. Ring “zero ‘no longer 


concerns itself with pathnames. Instead, it eooepts directory 


segment numbers for directory specifiers. To allow this shen: 
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to bootstrap itself, we will define the segment number of the 
parent of the root to be zero. Inttiation of segments and 
directories will be controlled by the proeedure initiate _ that 
will aécept a parameter specifing whether a segwhent or directory 


is to be initiated. 


The rationale behind distinguishing directory and 
segment initiation is that a process usually has a preconceived 
idea about the type of the object it wishes to initiate. When 
reality does not support this preconceived idea, the process is 
usually in error. Porcine the process to make explicit the type 
of object it i8 expecting allows ring zero to immediately catch 
many such errors, preventing a careless process from bumbling 
along thinking all is well only to die when it attempts to access 
a directory as a segment or vice versa. Naturally, it would be a 
sacurity violation for the kernel to report a type violation to a 
process that has no right to know whether the directory or 
Segment named actually exists. If a segment or directory should 
be undetectabdle to a process, then the security kernel must treat 
it in a manner consistent with the type specified in the initiate 


call regardiess of its actual type. 


To complete our new ring zerqg address space manager 
interface we must define a new termination primitive. This 
primitive will accept two arguments, The first argument 
specifies the segment number to be terminated. The final 


argument is a status code. It should be noticed that this 


~56- 


primitive may be called with either a segment or directory 
segment number. In the case of terminating a directory, one 
constraint is enforced. Since the system requires that a known 
segment's parent also be known, terminate_ will not terminate a 


directory with known inferiors. 


4.3.2 Details of the Design 


So far everything seems rosy. This scheme seems to 
remove many functions from ring zero and to simplify the ring 
zero interface in the bargain. Where is the hitch? Do we get all 
this for free? The. answer is, of course, no. ° We have glossed. 
over one important point. In order to .decouple directory and 
segment initiation we ‘must be able to successfully cloak the 
physical initiation of directories from.a process! detection 
until it has established its right to know of the existence of 
the directory. As was pointed out earlier,: this need for 
deception is intrinsic to the hierarchy structure and 
functionality of the Multics system. While this design makes the 
system's need to deoeive the user more obvious, it is not 


responsible for the required deceit. 


We will call a directory detectable if a process has 
established its right to know that the directory exists. 
Detectability may be established either by having nenenusa access 
to the directory, by having non-null access to its parent, or by 


establishing the detectability of an inferior of the directory. 
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The reason that non-null access on. the parent. of an object: 
establishes its detectability is that either’ status, modify ‘or 
append permission. to a directory is @uffictent te allow a process 
to detect if a ‘postulated entry’ in that dtreotory actually 
exists. It should be noted that the detettability* of a‘ directory 


is dependent on the process' history and the ring of execution. 


A directory is detectable by a process in rings zero 
through the highest ‘ring tnwwhton it’ ad "@eteckably “initiated 
some member of the tree rooted at ‘that @ireetory.° This tighest 
detectable ring number of a directory is*kept “in “its KSTE. (1y> 
We will not attempt.to reset this “fielé should a dice detectable 
directory subsequently bécome undétectable: ‘Wot “atteepting to 
reset the highest detectable ring ‘field “in “the "STE -of an object 
when it becomes undetectable to the process mikes ‘sénse since tte 
system has already admitted the ‘existende of the @irddtory to the 
process. The process * could have ‘stored this “information 
elsewhere, so it would be of little use ‘to: dehy’ the existence of 
the directory. The record tept in the ST of the lextstence OF 
the directory will naturally vanish when the “directory is 


+ 


terminated or when the process is. destroyed.” 


Sie PS, 


We must prevent a process | from detecting : any difference 


between an initiated directory that does, not What etme ie kee 


> 


initiated existing, but “undetectable, ‘directory. If a process | 


(1) See appendices A and B. 
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could detect a difference in these ‘two cases then “it could 
establish the existence of any poatulated path in the hierarchy. 
This would constitute a clear’ violation of security. To 
accomplish this means abandoning the current ‘one-to-one mapping 
that exists between occupied segment — number's and initiated 
segments and directories. Although we will still only allow one 
segment number to be bound to a segment, we must ‘allow multiple 


segment numbers for the same directory. | 


The reason for this dichotomy between segments and 
directories is simple. Since the aceess’ control: list of a 
Segment completely controls the right to initiate that segment 
there is no need to ellow a process © to’ initiate a segment to 
which it has “no- access. This allows us to hide the physical’ 
existence of a segment from a process that has no right to know 
of its existence by returning the ambiguous status code "noinfo" 
in response to an initiate request. This simple mechanism fails 
for directories since we must always allow a process to initiate 
an existing directory in case it has aceoess to some’ inferior of 
that directory. This forces us to return more than one segment 
number for a directory in some cases -in. order to prevent the 
process from detecting the existence of physically initiated but © 
logically undetectable directories. = ©... : . 


There are two characteristics of Multics that 
necessitate our abandonment of the current one-to-one mapping | 


between directory segment numbers” and directories. First, 
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directories can have multiple entry nahes.,:-if° initiate. returned 
the same segment. .nuaber for: two different: entry names within a 
given direqtory, then the pracess.woukd ‘know stat “these” “names. 
both named the .same dinectory... Thissedineiéence of ‘names would 
establish the existence of the directory (if the directory did 
not. exist, , then, how could it: have ‘two nanies?): ‘To ‘prevent the 
coincidence of. multiple names on a eet eee 
existence of the directory, we -must return a new segment “number ~ 
if a process reinitiates a directory that is = still undetectable 
with a. new... name.. In... fact;:we will even return a new segment 
number if it. tries to initiate an undetectable directory with the 


same name twice, If we returned the sane segment’ number, then ih 


order for directories that do: not: physically éxist to appear the 


same to. the.user ring,-ring zero.would havé’to remember the name — 
of every phoney directory; This tsa “needless” *oomplication of 


ring SECQ mes ares Sobrg age kp 8 danas Mae wets ae ar 


_., .. The .second characteristic ef Multics ‘that forces our 
abandonment, of the one-to-one mapping between. ‘directory ‘segment _ 
numbers and dineotonies..ia that -the segedit siuibers ‘of a process’ 
are a finite resource shared among all. protection rings of that’ 
process. . AS we have. commented earlier, the finite size of the 
Multics shared segment number address: space ‘allows’ one ring to 
detect the number of Segaent numbers being used by all other 
rings. This makes it necessary to assign a: new segment number 


whenever an attempt is made to initiate an undetectable 
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directory. This segment number must not be shared with another 
ring so long as the directory remains undetectable. The need for 
assigning private, per-ring segment numbers to undetectable 


directories may be-seen in the argument: that follows. 


Assume the system returned the same segment number when 
asked to initiate a directory in two different rings. Assume 
also that the directory is undetectable in the upper of the two 

rings. What is the system to do whem asked to unbind the segment 
number from the directory by the upper ring? It cannot unbind 
the segment number and return it to the list of free segment 
numbers since a lower ring is using the segment number. 
Unfortunately the ring that requested: the system to terminate the 
segment number can detect whether or not the ‘system actually 
returned the segment number to the free list so the system cannot 
just pretend to honor the termination request. ‘If ‘the “segment 
number is not freed then the rine can deduce that ‘some other ring’ 
has the directory initiated. By an argument similar to the one 
given in the previous paragraph the ring can contlude, from the 
coincidence of two rings having. the directory initiated, that the 
directory actually exists. Since segment numbers are a scarce 
resource, the system cannot take the-easy out of not allowing 
undetectable directories to. be terminated; As ai result, 
initiate_ must assign.a new segment numbee<whenever it initiates — 


an undetectable directory... 
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The reader. should note that we have: ignored, up to now, 
the problem.of preventing a process fpom distinguishing between a 
non-existent dinectery and an existegt but ‘undetectable directory 
through observation and analysis of ‘seooné “order effects such as 
the time required to initiate or terminate a directory. It is 
hard to predict ain advance of installation ‘in ‘the standard system 
what sort of second. order effects might be observed. The plan is 
to investigate this problem fotiowing actual ‘installation. 
Timing differences cen be. easily: hidden ty inserting extra code 
in the shorter path... Other differences ‘also probably are 


disguisable. 


| This seheme will«merrily aliow-a process to initiate 
vast trees..of directories that donot ‘ex£st.' These directories 
will be indigtinguishable from real undetectable directories. 
The potential -multiplicity of segment numbers for directories 
implies that if we compare two dineotory'ségment numbers and find 
them to be not equal, then we cannot doneludé ‘that the objects to 
which they are bound are not: one and the :same. ° Since processes 
running outside ring zero cannot: currently obtain ‘segment numbers 
for directories, no user code'.can be -affeeted by this new 
restriction. To allow processes to: quickly determine if two 
segment. numbers are bound:to the same objeét, the system should 
support a function for mapping: a segment number into the unique 
identifier of the object to which it is-bdundd, Naturally, this 


function must return an error if the object is not detectable to 
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the process. The system must also’ assure that if a process 
attempts to reference through any°diectory’ pointer in ‘an outer 
ring, it will get the samé acdess° violation’ whether or not the 
segment number it reférehted sera eepondey to” ” “Peal or phoney 


directory. 


Figure 4-1 ‘summarizes. “the actions ‘performed by 
initiate. when mapping a direétory: ‘inte a’ process’ ‘address. ‘space. 
The reader should note that a target “ébfeét within a’ phoney 
directory. is considered a priorf undetectable ‘and a non-existent 
target object is corisidered detedétabie- by < a’ “process if the : 
process has non-null access to the: containing ‘directory. The 
abbreviation "hdr".used in figure 4-1 ‘Stands for the contents of 
a KSTE’s. ee sae 


.target is detectable in ring of caller 0°" 


“ .target exists in hierarchy 

. « .tatget already has a segment: number ‘~~ 

Sn 528 return values Pe internal state 

..« .}status code}segment number} © (* "hdr 
See Re gle ae ee ee eg me ets pe ee eee ae eee SE Se SE OF OO Se OS Se ea Se Oe ee ee 
JO = -] -Fno_info" } new { PUREE aes ie 
11 0 =) “noentry" | none es oer dict tl 
11 1.0 QO foo) sew. f° “ring of caller | 
11 1171 “known" | old (max(hdr.ping. 9 of caller)i_ 
0 as om om OD am om Se am we ee ae ee ste sn a wee ow oes tl tt cent ts ti ew ah am cn cen fb 2 yk oe hs dk cen Sid aS aoe sim Ge tas ain mn oon a ste Sv om em en 


Figure 4-1: Action of Initiate_ for Directories 
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_ Iwo possible. objections. we. cas: see to-this..scheme are 
that it can potentially waste. segment- numbers: and it requires 
inspecting the parent's. access. control,,dist,- A elose:. examination 
of figure 4-1. indicates. that..there.are,eniy: two- ways><to- assign 
multiple segment numbers coe directory. The first way.is to 
reinitiate an undetectable directory. Ihe second is to initiate 
a phoney directory... Neither of theae:-operations sheeld occur in 
normal operation. They could, however, :arisesin: an attempt to 
use a misspelled pathname. To costro}-this: problem, the outer 
ring variant of find, could terminate these> directories ‘that. 
might be phoney if the terminal segment could not be initiated. . 
This would prevent.a habitual. misspelier. fram: cluttering. his: 
address space. It seems that with, this edditdon a process would — 
be obliged to. go out, of its way, in order: to: elabter. its address 
space. if, that is what. it, wants fine. cfiven: bf a process wastes 
all its segment numbers, it can recover by terminating no longer 
needed segment numbers. 2 2.0) owe ints 

The apparent. .inefficency. of: inespeeting: - the. . access 
control list of the parent of a directory. during::its initiation 
is not serious since it is nogwadly-neberequived. Only when a 
process has null access to an: objecks and kaso ‘not: previously 
established detectability for that.,-ebject is it neceababy<t0 


inspect the access control list of the parent..(#) x 


(1) In fact, the frequency with which a process initiates a 
directory to which it has has no acoess.ia how enough in Multics 
that our test implementation does not check to see if a process 
has previously established detectability for a directory to avoid 
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In Multics system 24.2 the address space manager and 
the reference name manager share a dita base. (1) Th e address 
space manager. takes advantage of ‘its: ‘ability | to access ‘the 
reference name manager's dat@ base by scanntrig the per ring, - per_ 
segment number, list of reference disiv's ‘Kept: By the reference 
name manager to determine which rings of ‘a proveds’ are still 
using a particular Segment’ number. This information is used to 
prevent one ring from terminating a segment. number that is still 
in use by another ring. (2) Only tf all rfngs that’ initiated the 
object have terminated it, can the segment number be unbound from 
the object. Thus, we have the concept of initiating an object in 
a particular ring rather than the. concept” of init dating an object 
globally in all. -rings of a proées’. ‘This schemé is desirable — 


since all. rings: share the address space ‘of Ségment numbers. 


Tape 


inspecting thé aecess ‘control: “tist . “the parent of the 
directory. If the process has null access to, 2 directory, then. 
we .always. check “the: ‘proééss" ‘ access “to “the — ener’ of the 
directory. 


(1) See appendix A. . 


(2) Since the address space manager uses ene: presence. of .. 
reference names in a given 2, genager use 4 ‘dumber to detect 

that the ring is still using the segment number, the current 
initiation primitive must call the reference name manager to give 
a segment a reference name in the appropriate ring each time the 


segment is initiated. The current initiate interface ee: ; 


the. address space manager with-a.peference for this” purpose. 
more complete description of the relation hip between the. adgneas 
space manager and reference names ‘it sywtent 2! 4.2 Hay. be. found. in 
Organiok [01]. 


Since reference names will’no.longer be kept in the 
KST, some new mechanism must be invented to supply information 
about which rings: ofa process are still using a “given segment 
number. © This is  e@aSily: accomplished by adding an eight bit 
‘field, called rings, to each KSTE. If the i th bit( 0 origined) 
in this field freee then thé corresponding ring has the segment 
number initiated. .This allows ring zero to detéct when a ségment 
number may be physically terminated, thereby preventing one ring 
from terminating a segment or direétory that is being used by 
another ring. (1) | 


Our termination primitive marks.the segment number it 
is given as free in its. caller's ring ‘of execution. If the 
segment number is initiated in no other rings and its inferior 
count is zero, then the segment number is unbound from the object 
and its KSTE is placed on a list of free KSTES. It should be 
carefully noted that the termination: primitive terminates a 
single segment number; it only removes. an object from the 
process! - address space if the last’ ségent number for the object 
is terminated. The reader should notice that. because initiate_ 
always assigns. a private ‘ seunent?? nibeh: ‘Whend aipsetory is 
undetectably initiated, terminate. need not worry about revealing | 


the existence of an. undetectable directory. - 


(1) Appendix B- sSummatizes the content of the known segment table © 
as we have redefined it. a 
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44 Removal of Pathname Processing 


Ring zero's ability to resolve. a pathname into a 
segment number has been severely impaired by our design, This 
ability, which was embodied in the ring zero procedure find_, 
depended upon rine zero's ability to call “the reference name 
manager. Specifically, find. dependéd ‘on the reference name 
manager to maintain an association between pathnates of objects 
and the segment number bound to the ‘object, Fortunately, this 
association was only used to make find. more efficient. As a 
result, we could redefine find_ in such a manner’ that it would 
still operate correctly but would not take advantage of such an 


association between pathnames and sezment ‘timbers. 


To make find_ independent of ‘the reference name 
manager, all we would need to do is redefine find. to inspect the 
pathname it was given to see if it- specified the root, i.e. “th, 
If it did, then find _ would initiate the root, and return its 
segment number. (1) Otherwise find_ would strip off the last 
component of the pathname and call itself recursively with the | 
pathname of the parent of the target object to get its segment 
number. Given this segment number, find_ would éall initiate to 


initiate the entry. named by the component which was previously > 


(1) The system treats the root’ directory asa special case. The 
location of its physical object map as wel] as the rest of the 
information that would reside in its directory entry, if it had a 
parent, is embedded in the programs of the _ system. This 
guarantees that the root may always be initiated. 


=-67- 


na, MAB EM op Ra Te RET GRRE Rie oo eget ee et 


removed from the pathname. For example, if .find_ were called 
with >a>b it would call itself recursively to get a segment 
nymber for >a. It would then call initiate .to get a segment 


number for the object named. b in the directory >a. 


While the procedure we have described is correct, it 
appears to he quite inefficient. . This inefficiency suggests that 
we should either give find. .4 new ageociative memory or move it 
out of ring zero so that it can once again use the reference name 
manager. Since giving find a new associative. memory would add 
code to ring zero which has no proteation reason to be in the 
security kernel, this alternative is untenable. Our approach 


will therefore be to remove find_ from ring zero. — 


The actual removal of find. from ring zero is, of 
itself, trivial. In the outer rings it can.aeceas the reference 
name manager directly once again. It. can also access our new 
initiation primitive through a standard gate into ring zero. The 
problem is that numerous programs in. ring zero depend upon find_ 
to map pathnames into. segment numbers. Unfortunately, they 
cannot be allowed to call our new find_ in the: outer ring. To do 
so. would jeopardize the seourity ef ring sere. To get ourselves | 
out of this dilemma, we will. have te remove almost all uses of 
pathnames from ring zero. This in itself represents a 
substantial simplification of. PANG BENQ: <9 Rane) *30 this task 


we will consider the four. major uses of. pathnames dn ring zero. 
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4.4.1 Parameters to Ring Zero 


The first class of pathnames .used..in ring.zero that we 
will consider consists of those pathnames that were passed into 
ring zero as an argument to a gate. pronadure «.. This class 
represents the major use of pathnames in ring. zero. Fortunately, 
it is also the easiest class to remove. from ,.ring.. zera. Since 
find_ now heeidea in the outer. ring, we will. make the outer ring - 
responsible for translating all pathnames , that. are currently | 
passed into ring zero into segment numbers... We will then 
redefine all ring zero gates that... accept _pathnames as object 
specifiers to. aadert segment. numbers. as. object specifiers 


instead. 


4.4.2 Links 


The second class of pathnames used in ping>zero are the 
pathnames contained in links. Many ring zero.programs, when they 
discover that the object they are to act. upon is a link, are. 
defined to act instead upon the target of the link. An example — 
of a ring zero function that is defined to.follow. this rule is - 


the segment initiation primitive. (1), We propose that primitives 


(1) To prevent a process from causing ring zero, which is masked 
against interupts, from looping. indefinately: follewing a circular 
chain of links, “ eath’ program that’ follows links keeps count of 
the number of links it traverses durigg.each imyocation. If this — 
number exceeds a certain system-specified threshold, then the 
computation is aborted. 
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which are defined to follow links return a status code indicating 
that a link has been encountered as well as the contents of the 


link itself, upon discovering that their target is a link. 


This scheme requires that links be readable in the 
outer rings which raises the question of what, if any, access 
control should be placed on reading links. The approach taken in 
Multics system 2%.2 i to take links ¢@ffectively readable by any 
process that has non-null access to the termital target of the 
link. This seheme has an inherent sevurity flaw and is therefore 
unacceptable, . If some process can guess the pathname of an 
existing link to whose target the process has access, then it can 
prove the existence of the parent directories of that link by 
initiating the target object through the link. To eliminate this 
security flaw we could place access ‘eontre! lists on links, 
thereby explicitly naming those processes which may read the 
link. The complexity of sudl & weehanism sééms unwarranted when 
weighed against its benefits. the only access ‘eontrol on the 
baredt object of the link that is guaranteed is specified by the 
access control list of that object. Any access control specified 
on a link may be avoided by referencing the target object 
directly and thus serves only to proteet the contents of the link 
itself. 


The reasons that access to links must be controlled is 


that the existence of a link implies the existence of its 
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superior directories and suggests the existence of its target. 
We have chosen a simpler mechanism for controlling access ‘to 
links which, although not as comprehehsive as ‘a mechanism that 
associates a private access control list with each link, meets 
both of the needs for protecting links. We consider a link to be 
part of its containing directory, readable only by processes 
having status permission on that directory. This ‘scheme: has the 
virtues of being simple, easy to implement, and plugging the 
information hole that uncontrolled access to ‘links provides in 
system 24.2. While this scheme does make Orie class of currently 
‘ legal uses of links illegal, this restriction does not seem too 


severe. 


To illustrate the scheme we have proposed, we will 
outline the redesign of link processing by ‘the ring zero 
initiation primitive. When initiate_- encounters a detectable 
link, it will return the link and a status code that informs the 
outer ring procedure that a link was encountered. (1) The outer 
ring procedure ay then try the new path specified by the link. | 
Since this is happening in an outer ring, we need no longer have 
a standard interpretation of links. Since. link processing will | 
be done in the user ring, the process may interpret links in any 
manner it chooses. Why not let links contain relative pathnames, 


offsets, or even arbitrary character strings? A link might even 


(1) As we have mentioned earlier, if an undetectable link is 
encountered while attempting to initiate a directory, the system 
must treat that link as an undetectable, phoney directory. 
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specify a file residing in another computer system. The 
important point is that while the kernel may be the keeper of 
links, it does not interpret them. Naturally, the restriction sii 
link depth, which was intended. to‘ keep ring zero from getting 


into trouble, vanishes. 


4.4.3 Internally Generated Pathnames 


Ina few cases, ring zero generates and uses pathnames 
internally. These generated pathnames constitute the third 
general class of uses of pathnames in ring zero, We will further 
partition this class into those pathnames that are generated only 
during system initialization and those pathnames§ that are 


generated during normal system operation. 


During the initialization of the Multics system, the. 
need arises to initiate on the order of one -hundred se fewer 
segments. The reason the system must initiate these segments is 
of little interest to our thesis. We observe that since system 
initialization is an infrequent operation {hapefully once a day 
or lees) and the number of pathnames..to be resolved is quite 
small, we need not feel remorse at proposing a very inefficient | 
mechanism to resolve these pathnames. In fact, as the reader has 
undoubtedly guessed, we propose that these pathnames be resolved 
by. calls to the inefficient version of find_ that we described 


earlier. 
a . 
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In the case of pathnames generated by ring zero’ during 
normal system operation, we cannot be quite so cavalier. Or can 
we? In fact, we can. A careful examination of ring zero reveals 
that ten is a reasonable upper: bound on ‘the’ number of generated 
pathnames that must be resolved ‘in ring zero in the life of any 


given process. 


In fact, these internally generated pathnames are _ so 
restricted that we have no need to even call our inefficient 
find_. Since they all are of tree depth at most: three and all 
components of these pathnames except possibly the last component 
are constant for all. time, we could expand the code of find_ in 
line in the programs. that use these pathnames. For example, if a 
program needed to initiate >pdd>my, then it would first initiate 
the root. Then, given the segment number of the root, it would 
initiate pdd. Finally, given the segment number of pdd, it would 
initiate my. 7 mo 


4.4.4 Error Conditions 


The Tant and perhaps most troublesome ‘eles of 
pathnames used in ring zero are pathnames that are used to report 
error eondit tons. There écink numerous instances in the Beaten 
where a procedure: detects an inconsistency or error condition 
associated with some segment dé -dinectons< For i natanee: the 
System may detect an unrecoverable error while reading the 


contents of a segment. Another example would be the detection 
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that the doubly threaded list which chains the entries ina 
directory together is misthreaded, .-In errer conditions such as 
these, the system writes a message into the system log explaining 
the problem. Thies message often contains a pathname that was 
generated from the virtual addreas of the segment or directory in 
which the error occured. While the exact algorithm for 
generating a pathname from a virtual address is of little 
interest to us, this algorithm did depend upon the reference name 
manager's ability to map a directory segment number into a 


pathname of the object it was. bound to. 


Since we have argued that ring sero must not call the 
outer ring name space manager, we must. propose. a .new algorithm. 
for mapping a segment number into @ pathname. Many sehemes are 
possible. However, since the error conditions we are talking 
about may be presumed to be quite rare, we will suggest a very 
Simple, but inefficient, algorithm. This algorithm relies: on the 
fact that any virtual address may be mapped, by the known segment 
table, into the virtual address of its dipectoey cathy. A name 
for the segment can be found in the directory entry. This name 
is the last component name in a valid pathname of the object. To 
get the other components of a pathname of the object, we 
recursively apply this technique to the virtual address of the 


directory entry which is, of course, within the parent directory. 


a 


4.5 Summary of the Design 


This . chapter has presented a design that allows 
directories to be initiated ‘in all ‘Fings. As a consequence, the 
need for the Multics security kernel to maintain reference names 
has been eliminated. The key feature of this design is that the 
security kernel maintains, for each process, the illusion that 
any postulated directory exists unless the process has surficient 
access to prove otherwise. This permits the security kernel to 
allow a process. to initiate a directory to which it has no access 
without disclosing the existence of that directory. The address 
space manager interface presented in this deste is adanabined an 
appendix C. Appendix D contains an example of the nae of this 


interface. 
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As a result of our design, the interface to ring zero 
has been modified quite extensively. We have eliminated three 
major functions that. ae supported by. the. old ring zero: 
reference name management, pathname . resolution, and storage 
system link indirection. If the anon-kernel portion of the 
Multics supervisor is to use these services. or provide them to 
the users of the system, then we must design modules capable of 
providing these services that run outside of ring zero. We have 
already explained, to a degree which we hope is sufficient to 
convince the reader, how the last function.may be trivially 
performed by outer ring modules. In this chapter we will discuss 
the important issues involved in resolving pathnames in the outer 
ring and designing an outer ring reference name manager. In 
addition, we will address ourselves briefly to the problem faced 
by user programs that depend upon now obsolete ring zero 


interfaces. 


5.1 Reference Name Manager Design 


We have seen that the Multics reference name manager 
provides four primitive functions on name spaces. These 
functions provide a process with the ability to: bind a name to 


a segment number, unbind a name, determine the segment number 
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that a name is bound to, and obtain a list of’ the names bound to 
a segment number. Actually, the Multios reference — name manager 
provides a larger set of fumetions. However, the additional 
functions all can all be expressed: in’ teres of _the four 


primitives we have described. 


It is not our intention to actually design a referénce ” 
name manager. We trust that the reader will aecept our assurance 
that it can be done and that it is in faot straightforward. We 
must, however, comment on one consideratdon that’ the? design’ of an 
outer ring reference name manager must recognize. When the name 
space manager resided in ring zero it was operating in an 
environment in which it was guaranteed to run'to completion once 
invoked. An outer ring name space-wesager is:not afforded this. 


luxury. 


Executing in the outer ring environasnt, the reference © 
name manager may be stopped at any instant. This of little 
consequence except when it is stopped by: the Muitics "quit" 
mechanism. In this case, the system suspends the process! 
current computation and then restarts the provess; The process 
may then reinvoke the reference name manager and.at.a later time 
resume the suspended computation having potentially totally 


rearranged the reference name manager's data base. 
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Luckily the system provides a mechanism that allows a 
process to inhibit or. "mask" quis: sighel®. By masking quits on 
entrance to the reference name manazer and unmasking quits anon 
exit the problem. can be eliminated. Actually, it is highly 
unlikely that the entire computation performed by the reference 
name manager need be masked. We should design the reference name 
manager so that it has.as small a “éeittoal™ section or sections 
as possible. In other words, we should try to isolate the code 
that might malfunction if it were not masked against quits. We 
can then mask and unmask quits only when we eiiter and exit a 


critical section. 


. Before leaving the topie of name space management, we 
should comment. on one consequence of “aliowing processes to 
initiate directories directly. This ability allows a process to 
use the reference name manager to bind an arbitrary name to a 
directory, One immediately obvious use of this new facility is 
to replace the current special purpose mechénism that identifies 
a process' per ring working directory atid search directories 
[01]. All we need. to do is bind the appropriate name, i.e. 
"working dir" or "search dir_n" to the eorrett directory segment | 


number. 
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5.2 Pathname Resolution 


We have commented that reference names are per ring. 
This prevents programs executing in one ring from causing 
programs executing in another ring to malfunction by tampering 
with shared reference neuen: As a result, ring four could bind 
the name "sqrt" to one procedure and ring one could bind the same 
name to an entirely different speasdukes While this multiplicity 
of name spaces per process is desirable for. protection and 
modular programming reasons, it partially defeats find_'s purpose 
in using the reference name manager to bind pathnames to segment 
numbers. Since each ring has a different name space, associating 
the pathname >a>b with segment humber 401 in one ring will not 
help another ring resolve. yard. The result is that many 
redundant pathname resolutions will occur and many name spaces 


will contain identical entries. 


We suggest that find. not use the reference name 
manager to associate pathnames with segment austere. In fact, it 
was never correct for it to have done so. A name space just 
associates an arbitrary name with a segment number. However, 
pathnames are not just arbitrary names. Consider, for instance, 
what happens when we remove the name b from the directory >a>b 
and then add the name b to the directory >arc. The result of 
this change in the environment is external to the reference name 


manager and yet it has invalidated a mapping the reference name 
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manager was keeping. The pathname >a>b no longer refers to the 


object that is bound to segment number 401, but the reference 


name manager has no way of knowing this. 


There are potential advantages to binding pathnames to 
directories once per process, as is che an Multics system 24.2, 
Consider the problem of installing a new veveion of a 
multi-component subsystem, such as the Multics PL/I compiler, 
while Multics is running. In Multics system 24.2 we could store 
the components of the compiler in a stogie directory: To install 
a new version of the compiler all we would need to do is build 
the new version in a brother directory of the current compiler. 
When the new compiler is ready for installation all that would be 
necessary is to exchange the names on the new and old compiler 
directories. Processes that had already started £6 ise the 
compiler would remember the segment number of the old Aipeot bry 
as the compiler directory and would eontinue to use the old 
dompiiee and satisfy new dynamic linkage faults to components of 
the compiler from the old directory. In this "way 7 process 
always gets a consistent copy of the compiler. A process that. 
had not yet used the compiler would initiate the directory 
containing the new compiler when it atteapted to ingeke he 
compiler. It would then remember this new directory as the 
compiler directory and satisfy all linkage faults for pieces of 


the compiler from this directory. 
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If a process. does not "freeze”a directory ‘sub-tree, as: 
is done in system 24.2, when it initiates. that directory, then tt 
becomes very difficult to do on line installations of 
multi-component subsystems. A process could easily get half of 
an old multi-component subsystem and«haifiof: a‘ riew ‘version of 
that subsystem. when, an online taataliatian ‘ofthe subsystem: fs: 
done. On the other handy -# precesa Often wants ‘to use ‘the actual’ 
hierarchy, not a "frozen" image of tine ~ hierarchy. Our - design 
allows a process - to cheese between these two: ‘alternatives oY 


Supplyiing an appropriate version. of. find in: fae orber ring. 


we. suggest. that the... system. auppiied find. opt for” 
“solving the "directory renaming problem". rather. than the "online - 
installation problem". The: easiest. and: most: attractive — approach: 
to solving the directory renaming problem is to not allow find_ 
to use a pathname, segment number assotiative’ mewory. ’ Instead, 
find_ will always recurse to the: ret: when resolving: a*pathnaie. 
While this might seem unattractive for efficiency reasons, direct © 
measurement of. the ‘Ampact of. suoh: a: schema’: cupon’ system 
performance reveals that system throughput. would only be degraded” 
by a small fraction...of a peroent.:.*In.addttion, éur proposed’ | 


address space manager will. drastically :)neduce™ “the number -“of*: 


pathname resolutions that occur within ‘the: ayeten.” This - 


reduction in pathname resolutions should render: ‘the difference 
between find_'s having and. not having a pathname associative — 


memory almost immeasurable. This slight performance degradation 
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seems a amall price.to pay: fer the-elimination- of the directory 


a 


renaming problem outlined above. oo @oo> 
dt, . ee 5 
The final;.topic we wish to-:@iecuss ta this” chapter is 
that of. compatibslity. -A basic responsi bilfey”of any computing 
utility is to minimize the effeet ofintertal” dManged® ‘upon its: 
user community. If a major-ehange must-bd meade in the interfaces 
between user written programs andthe ‘system; ‘or “fr the semantics 


of these. interfaces, then the systew mist ‘dippért both the new 


and old interfaces for.a sufficiently long period of time to 
allow users to convert ‘their programe to vse the sew interfaces. 
A suitable. measure of this period of vine ‘would probably be 
measured in months. on even years; nob hodrs, days, or weeks. 

We have made aubstantial changes to” the ring zero 
interface .and. thus. must address the compatibility “issue. 
Fortunately, it. 4s quite simple to: preserve: dompatibility without 
keeping the old find, end name: and\addrwss:spacé- managers, This 
is. possible for two: reasons: First, ‘wé-¢an: simulate the old ring 
zero. interface by interposing a rangifour |‘ prodedure between the 
caller..of an.cbsolete-ring zero tntérfadé ‘and our new ring zero 
interface. Second, it is possible to intérposé°-such Simulation 
procedures between. the user. and the new 'rftig zero interfaces 
without recoding or even recompiling aty ‘usd? ‘grograms.. , 
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Consider how we would simulate the old interface to 
initiate. The outer ring-interposing procedure would call the 
outer ring reference name manager to map the pathname directory. 
specifier of the old interfaoe! into the ségmbht dumber required 
by the new interface. It would then call ‘the new initiation 
primitive. if this returned a link,’ ‘the: buter’ rine interposing 


ziti 


procedure: would start over again, 


This simulation: procedure would’ be‘ difficalt to. 
implement if. it were not’for the’ fact that’ Maitics now has an 
interposing procedure on all°ealls: to Ping %éro: This procediire 
isa ring four transfer vector that Hormally‘tfansfers the call 
to the appropriate ring gero-gate. (1) This-transfer vector can 
be modified so as to call an appropriate interposing interface 


simulation procedure for the interfaces’ we have changed. 


THER 


(1).This transfer. vector, which ‘waa @iseus¥ed in ‘a ‘previous. 
masters thesis by Janson [J1] has not yet been installed in the 
current Multics systen. 
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We have coded a test. implementatiom of the essential 
features of our design. This test implementation, which is based 
on Multics system 24.2, was undernteken for four major reasons, 
First, a working implementation of. ow ideas serves as an 
existence proof of the basic claim of our thesis. Second, a 
working implementation helps us demonstrate the practicality of 
our design. Third, the aetual task of implementing our design 
helps insure that we have not megleeted any important details in 
our design. Finally, a test iaplementation.of our design helps 


us to quantify the impact of our design upon the system. 
6.1 Plan 


We have indicated that our new design requires an 
extensive overhaul of ring zero. The pervasiveness of the 
modifications necessary to ring zero is largely a result of the 
removal of pathnames from ring zero. While the removal of 
pathnames from ring zero is essential to our design, it is a time 


consuming, straightforward, and intellectually unrewarding task. 
Instead of undertaking this drudgery, we have devised a 


scheme that allows the essential ideas _of our design to be 


implemented while avoiding most of the. uninteresting work. The 


® 
by 
3 
4 


implementation we will describe does not affect any code outside 
of ring zero, nor does it affect the syntax or semantics of the 
interface to ring zero. AS @ result of this feature, our test 
implementation provides the first step in af-orderly transition 
from the current Multics system to the system ‘we have described. 
The implementation we will describe: ‘could ‘be © immediately 
installed in the standard Multics system without substantially 


affecting users. 


What we elected to do was to dmplement our new 
initiation, termination, and name space management primitives 
inside ring zero. We then reimplemented, inside ring zero, the 
old initiation, termination, and name epede'wanagement’ primitives 
using our new primitives, This scheme allowed us: to concentrate 
upon the key issues of our design without getting bogged @own in 
the mechanics of converting thirty or’ more large Gomplex programs 


from using pathnames to not using pathnames.° >" 


The strength of this approach-is that the modules in 
ring zero may be slowly .weaned away from using patHnames or’ now 
obsolete interfaces. ‘Also, by supplyitg Sgates* to our new 
primitives, users of Multics can start converting their programs 
to take advantage of the new ring zero“interface. ‘When ring zero 
has been eompletely converted, all weineed do fis throw away the 
code that implemented the old primitives in terms of the new 


primitives and move the reference name manager out of ring zero. 
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6.2. 


Reducing the complexity of: a system certainty inereasés 
its certifiability [D1t, D2, D3, bt, ot, PT]. ‘Im order to 
substantiate the .hypothesis that our .¢esign results in a system 
that is more certifiable than Multics system 24.2, we will look 
at two measures of the complexity of the security kernels of the 
two systems. These measures are the difference in size of the 
old ring zero and our new ring sero and the difference in the 
number and complexity of gates into the odd ring wero and our new 


ring zero. 


Appendix E summarizes the adze:comperison deta between 
the old ring zero and our mew ring zero. - ks it reports, the 
address space Manager was reduced in size: -by) seventy-seven per 
cent. This. correaponds to a two and a haif percent reduction in 
the size of ring zero. En fact, the address spate manager that 
we designed was s0 small that we have presented it in appendix H 
for the reader. to peruse. This sizeable reduction. in the size of 
the. address space manager is quite: eneoeragisng and substantiates 
our claim that we have produced:a more. certifiable ring zero, 
What is even more encouraging lathat white this figure is fin 
itself substantial, it-only represents S:partial inplementation. 
Several modules in. ring zenro accept botir pathnames and segment 
numbers as storage system object ‘epectf ters. .-In a complete — 


implementation of our design many of these modules would only 
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accept segment numbers. This would allow the code that Handled 
the pathnames in these modules to be thrown out of ring zero, 


further decreasing: its complexity. 


The old-ring zero supports’ about. two -hundred gates. 
Our design olearly. removes .the necessity of having gates ‘into: 
ring zero which call the; reference name manager?” It also removes 
a whole class of gates: that-.allow an. object to be ‘specified “by” 
pathname. Many gates inte the old ring zero cate in pairs.” One 
gate would specify the target ob ject ubycosegment number, “fhe” 
other gate would specify the target object. by pathwame. ‘with the 
ability to. initiate directeries..in. the: -outer- rings, ‘this 
multiplicity of gates becomes unnecessary.:: As a result, ‘only the 
gates that take a-segment number as. object: specifier’ wold “be” 
retained in. the. ring. sero of a complete ‘inplewéntation of ‘our 
design. When we add up the number of gates stat ao full 
implementation of our design would remove from the current ring 
zero. interface, we find. that we woulat: remove “about Tive per cent 
of. the gates... In addition to reducdaig the’ number of gates into - 
ring zero, we. have. significantly simplified: the interface to over © 
fifty of the gates. that must remain’ in ~ring zero.’ (1) ‘This: 
reduction in interface complexity also aends credibility to our’ — 
Claim that we-have made ring zero, ‘and: henee “Multies; more. 
certifiable... ? ? ee 


(1) Seé appendix Go: . iesce. bee) oS nee leh stan 
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To help assess the impact of our: design upon the 
performance of the Multics system, we developed a small benchmark 
that tests the speed and paging behavior of the most used system 
funetionsa that our design. affected. °%h13 benchmark was’ run on 
both Multics system 24.2 -and our. test> implementation. The 
results. of these runs indicated that thé virtual epu time to 
initiate and then. terminate an <object drépped from 11.002 
milliseconds in the standard system to 10.226 milliseconds in our 
test system, a@ reduction of etgnt per -eent. (1) This is 
especially gratifying since the best “rawe “apace manager — we 
implemented was not in the least optimized for running speed. In 
addition, our test implementation was urfeirly penalized by 
having to converse with our benchmark through a simulation of the: 


old interfaces. 


: We attribute this speed up to many fattors; not the 
least of which ia the fact that we greatly simplified the 
structure of the known. segnfent table. We also make the’ somewhat 
immodest claim that our initiation, termination, and reference 
name management. primitives were simply ewded Better than those in 
system 24.2. But this is not surprising; most’ things are done 


better the second time around. It should also be noted that the ~ 


(1) A description of. our benchmark as well as a brief summary of 
the performance data can be found in appendix F. 
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smaller and less complex a module is, the easier it is to program 
that module efficiently and correctly. Unless a programmer’ can 
hold all of the relevent details and specifications of a program 
in his head at one time, it is very difficult to perform global 


optimizations or simplifications of the program. 


Our working set performance data indicates that our 
system referenced two more pages running the benchmark than 
system 24.2. This did not come as much of a surprise. One of 
these extra page faults resulted from splitting the code of the 
reference name manager and address space manager apart and the 
other resulted from splitting apart their shared data base. We 
anticipate that when programs are converted to use the new 
interfaces directly the extra page fault that was caused by 
splitting the code apart will be compensated for. We expect that 
Since our code is smaller in total, by eliminating the simulation 
code we will decrease the working set by a least a page. This 
will make up for the extra page fault caused by splitting the 
reference name manager and address Soaee manager apart. The 
increase in working set due to splitting apart the known segment 
table cannot in itself be avoided. However, this increase in 
working set is only on the order of a half of a page and is 


independent of the combined size of the new data bases. 
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We have not really put much effort into the performance 
arguments above, We feel that the performance data which we have 
peponted above is not, in fact, a good measure of the performance 
of a full implementation of our design. We claim that there is a 
hidden performance factor which -will easily swamp out the 
performance effects we have been discussing. Fortunately, this 
hidden performance factor ia in our favor. The effeet to which 
we are alluding will not be seen immediately but will slowly 
assert itself. This effect has to do with the gradual conversion 
of major supervisar and user programs to use segment numbers as 
directory specifiers. Since pathname resolution is fairly 
expensive (even when find. is given a pathname - segment number 
associative memory), the use of segment nubibers -as directory 
specifiers will save an average process a substantial amount of 


computation. 
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We have argued that reference name hanagement need not 
be supported by the security kernel of a computing utility. In 
particular, we have demonstrated a transformation on the Multics 
system that removes reference name management from its security 
kernel. Our design has further: simpitfied’the “Multics® security 
kernel by allowing. directories tebe initfated ‘outside of ring 
zero, and removing the conoept of a storage system’ link from ri 
zero, In the process; we have répaited ‘an inherent security flaw 
in the current Multics design that allowed ‘processes to ‘detect 
the existence of objects in the storage system hierarchy to which 
they had no access. This flaw resulted from having insufficient 
access control on links and from’ring %ero's failure to terminate 
undetectable directories: Finally, wevhave provided a ‘ golution 
to the problem of clearing find_’s pathname associative memory 
when a directory is renamed. — poe : 

We have used a technique in our redesign of the Multics 
system that we feel deserves ‘special *mention, This technique 
involves construeting a careful lie to maintain the Security of a 
piece of data. In our case, we constructed a sécurity kernel 
that lies about the existence of a directory  untiY the caller 
proves its right to know of the existence of the directory. “This 


lie, which was actually quite easy to ‘maintain, prevents a 
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process from detecting directories that should be undetectable by 
pretending that all possible pathnames correspond to an existing 
directory unless the process has sufficient access to the object 


specified by the pathname to prove otherwise. 


We have implemented.and heated: the.key. points “of our 
design. This implementation . has. shown: that our design is both 
simpler and more efficient than Multies 24.2. More details of 
our design than were presented in the body of the thesis may be 
found in the appendices that follow. In.particular, appendix 4H 
sneseite the actual programs of the address space manager 


designed in this thesis. 


In conclusion, we would like to note threa: observations 
we made while designing a new address, space manager for Multics. 
First, our address space.manager, which ia: far simpler than the 
current Multics address space manager, eles is. more efficient — 
than the current address. space manager... Tee complexity of the 
current sdbeésa space manager cost Multics both space and 
performance. (One. is tempted to believe that, in general, 
complexity added to improve .performance is frequently 
counterproductive.) Second, because Multics..is an existing 
system, the functionality and use patterns of the Multics address 
Space manager were thoroughly understeod when we began our 
research. A large part of the simplification achleved is the 
direct result of insight extracted. by observing the existing 
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implementation of these mechanisms. Finally, we noticed an 
impressive threshold effect. As our design progressed it got 
Simpler and simpler. At a certain point, when our design was 
Simple enough so that all of the relevant details of the design 
could be considered simultaneously, our design underwent a 
further drastic simplification. This simplification was only 
discovered when the mechanism became simple enough and small 


enough to be kept in the head of one designer all at one time. 
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The main data base for the Multies system 24.2 ring 
zero address and..reference name manager. is the Xnown Segment 
Table. The EST is: a per-process, ring zero segment. ‘Logically ~ 
it contains three items. First, it contains an array of KST 
Entries. KSTES are indexed by segment number and contain all> 
per-process information necessary for the proper care and feeding 
of the segment or directory associated with the indexing segment 
number. Second, it contains a hash coded mapping from the space 
of Unique identifiers ants the space of segment numbers, or 
equivalently the space of KSTEs. This mapping provides the means 
of locating the... KSTE of an already initiated segment should it 
subsequently ie ‘initiated by a different name. Third, it 
contains a hash coded mapping from the space of names onto the 
space of segment numbers. This association is mainly of use to 
the dynamic linking sigchattan. The current aun esate of a KSTE 


and their major usages are given in the following table. 


KSTE Field 


forward pointer, 
backward pointer 


unique identifier 
name pointer 
inferior count 


‘parent segment number 


entry offset 


directory switch 


 Uge - 


These pointers are. used to chain. 
the KSTE onto ‘a list’ of free KSTEs 
when it is not in use, 


The unique identifier of the 
segment: is used to validate UID 
hash searches and to properly 
identify the corresponding 
directory entry after an on-line” 
salvage. 


This pointer chains together a list. 
of the reference names associated 
with =this segment or directory. 
Stored with each. reference name is 
the number of the ring’ in’ which | ‘the 
nam= ‘t@ known. 


The inferior count records ~the 
number. of inferiors of a directory. 


~-thatcarpe in the processt address 


space, This information is used to 


prevent a directory from being — 


terminated while it has-known sons. 


This ‘entry records the segment 
number: of this segment's parent. 


oIt isfused at segment fault time to 
help: ~ locate this segment's 


directory entry. It also is used. 
to translate segment “Humbers into 
pathnases. 


This “éntry, which records the 
offset of this segment's directory 
entry within, its parent, is used in 
conjuction with. parent segment 
number to locate the segment's 
directory entry. 


This flag, which is set to indicate 
that the segment implements a 
directory object, is used to 
special case access setting for 
directories at segment fault time. 
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Our redesigned KST has been simplified and contains only two 


components: a KSTE array, and a UID hash table. The contents of 


each KSTE and their major uses are summarized below. 


KSTE field 


forward pointer, : 
backward pointer 


unique identifier. 


inferior count 


entry pointer 


directory switch 


rings 


highest detectable ring 


Use 


Used to thread KSTE onto free or 
hash class list as required. 


Unehanged (a phoney directory will 
have a uid = 0). 


Unchanged. 


A pointer to the directory entry 


for this segment. 
Unchanged. 


An eight bit field containing one 
bit. per ring. Whenever ring i has 
this segment number initiated then 
bit isof this field is on. 


. A.number that specifies the highest 
- Ping. in. which this process has 


established its right to know of 
the existence of this directory. 
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The proposed ring zero address ‘space manager interface is as 


follows. 


initiate_ (dirsegno,ename,dirsw,link,segno,code) 


dirsegno segment number of the “parent (input) 


enanme entry name of target (input) 
dirsw directory switch (input)... 

link — Link (output) . 

segno segment number of target Cauvput) 
code status code (output) 


possible status code values: 


error_ table _$segknown --- segment slveady known to process 

error_ table _$invalidsegno --~- parent is. not a directory 

error_ table _ $noinfo nay gene seien: access to return any 
dnformation. 

error... tabie _$nrmkst --- no more room in ‘known segment table 

error_table_$no_entry --+ entry does not exist 

error_ table _$wrong_type --- entry is of the wrong type 

error_table_$link --- entry is a link 


terminate_{segno,code) 


| 
segno segment number to be terminated(input) 
code see above. 


possible status code values: 


error_table_ $invalidsegno --- segment number is not bound to 
an object 

error_table_$infcnt_non_zero --=- can't terminate due to 
active inferiors 

error_table_$known_in_other_rings --- can't terminate due to 
segment number being used in other 
rings 
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APPENDIX. BD. 
Exagnis. . 


To help clarify the ideas...presented in this thesis, 
let us consider the following scenario in which a process tries 
to initiate the segment >a>b>ard>e>f in ring four. We will 
assume that directory e and segment fda net. exist and that the 
process has no access to a, b or d, and append permission to c in 
rings zero through four. We. have presented below a 
representation of this path through the hierarchy along with the 


process' access rights to each object in ring four. 


“root? <-- status 
<-- null 
<== null 


<-- append 


Q--02 --O--w ~ 


<== null — 


To simplify matters we will ignore the existence of the outer 
ring reference name manager and we will assume that we are 
operating ina virgin environment. What follows is how the- outer 


ring find_ would proceed in this case. 
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step 


step 


step 


step 


step 


step 


step 


step 


call initiate_(0, nit eT; link, 18egno_ of_root,code) 


The root directory will be” “initiated, its detectable 
field in the KSTE will be set to four, and a status 
code of zero will be returned, (all processes have 
Status permission tq the roat : direatory): - : : 


call 
initiate _(segno_ of poot mak, 1, Link )segno_ of_ a, code) . 
The directory wild be initiated, its detectable field 
in the KSTE will. be. set to. four,. end, a status: code of 
zero will be returned. 


“11 initiate_(segno_of a, "b", 1, Link segno_ of. b, code) 


“The. directory “will be initiated oe its detestable field 


in the KSTE will. be set.to..gero;.and - then. status eode 
noinfo will be returned. 


ll ‘initiate _(segno_of_b,"c", - slink, ,segno_ of_ Cc, code) 


-fhe directory will ‘be initiated, “its ‘detectable field 


in the KSTE wil] .be set to-four, and: g@.zero status codé 
will be returnéd. In addition this initiation 
establishes the process’ .right.to.Know.of -the.existence. 


of ‘supertor directories at least in rings zero through 


four. This is reflected, _in.»this-qase, by «setting the 


detectable field “in the ESTE of dard to four. 


call initiate _(segno_. of oe, tan, 1, ‘Link segno_ of 4, code) 


The directory d will be. ‘initiated, ‘its detactable field 


in the KSTE will be. set to faur,.- and. ‘A zero status code: 


will be returned. 


call initiate. (segno_of_d,%e",1,link,segno_of_e, code) 
The non existent directory e will be assigned a KSTE 
which will be marked as phoney and the status code 
noinfo will be returned. 

eall initiate (segno_of_e,*f",0,Link segno_of_f,code) 


No KSTE will be assigned and the status code noinfo 
will be returned. 


call terminate_(segno_of_e,code) 


The segment number assigned to e will be released on 
the grounds that e may not really exist. , 
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In this appendix we summarize. comparison data between 
the size of the Multics system 24.2 security kernel and the size 
of our proposed Multics security kernel. We have only included 
data for the: ma jor see hkais that were affected by our design. As 
a basic measure of the size of a procedure we have chosen the 
number. of words of text in its Multics object code module. This 
corresponds ih yy to the number of machine instructions in the 
module. We notice that in most cases the procedures in our 
system are markedly smaller then their counterparts in system 
24.2. Our reduction of the security kernel by 3345 words or 
about two and a half per cent may not appear spectacular, but the 
reduction in size of the address space manager is seventy-seven 
per cent. This has substantially reduced the complexity of the 
security kernel. The reason we can make this claim is that while 
the reference name manager in system 24,2 is not. that large, it 


is complex far out of proportion to its size. 
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old procedure 


find. 
makeknown 
kstsrech 
kst_man 
makeunknown 
initialize_kst 
initiate 


kst_entry_check 


size new procedure 
791 128 find_entry 
732 - 164 makeknown_ 
HHO 103 kstsrch 
4S 34 get_kstep 
1044 123 terminate_ 
667 82 initialize_kst 
698 288 initiate_ 
112 88 kste_info 
84 kste 
86 validate_segno 


4529 1184 
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APPENDIX F 
Performance Data 


In order to measure the change in overall performance 
between our system and Multics system 24.2, we developed a 
special benchmark program. This benchmark was designed to 
evaluate only the most commonly ‘ised features that: we modified in 
our design: segment initiation, reference name management, and 
segment termination. Specifically, our benchmark called the old 
ring zero initiation interface (1) to initiate a segment and give 
it a reference name. It then used “the terminate by segment 
number primitive of the oid interface to terminate the segment 
and unbind the reference name. This was repeated one hundred 
times. The virtual cpu time in microseconds 'ei complete the 
benchmark was then divided by one hundred to obtain a normalized 
_ performance timing datum. ‘The total auaber of page faults for 


the run was also recorded. 


‘The benchmarks for both systems were run on December 
10, 1974 within ten minutes of each other on a dedicated 
computer. The standard Multics system used was designated as 
Multics system 24.2. Our test system was identical to system 
24.2 except as it implemented our design. Three runs were made 
on each systen.. The first run served only to cause dynamic 


linking to occur and to bring the pages that our benchmark 


(1) The old ring zero interfaces were simulated in our system. 
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touches into primary memory. Th@ia@eond run, which took no page 
faults, was used to. obtain our: timing datay: (4) Multics system 
24.2 averaged 11002 microseconds for each iteration of our 
benchmark. Our test implementation was hetualty seven per cent 
faster, taking 10226:mieroseconds: per intération. The final run 
was made after the contents of primary “memory were ‘flushed. This 
run established .the size of the workffg set of our benchmark 
since each page touched while running our -benéhiwark produced ‘a 
missing page fault. The working set of our benchmark in Multics 
24.2 was five pages. Our. test..implementatién had a working set 


of seven pages. 


(1) Prior testing had shown that multiple runs of the benchmark, 
under identical conditions, produced times within one hundredth 
of one per cent of each other. As a result one timing run was 
all that was required. 
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This appendix lists briefly the changes we have made 
in the ring zero interface of Multios. system 24.2. We have 
excluded from this appendix the changes we have made to the ring 
zero address space manager interface as these changes have. been 


documented in appendix Cc. 


hes_$chname_file 
hes_$fs_get_path_name 
hes_$delentry_file 
hes_$fs_get_ref_name 
hes_$fs_get_seg_ptr | 
hes_$status_minf 
hes_$terminate_file 
hes_$terminate_name 
hes_$terminate_noname 
hes_$truncate_file 
hes_$set_be 
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hes _gadd_ acl_ entries 
hes_$add_dir acl entries. 
hes_$add_dir-iacl. tsiry 
hes_$add_iacle*ehtries~ 
hes_$del_dir_tree ~  °- 
hes_$delete_. aci- centriés 
hes_$delete_. dir~ aot eptties 
hes_$delete dif. athe nt tries 
hes_$deléte... feet Le_€ tries 
hes_$@ét._authdr’ 
hes_$get_bce_author 
hes_$get_ dir Seine weasietn: 
hes_$get_max_length 
hes_$get_ring_ brackets 
hes_$get_safety_sw 

hes  $get_ user_effmode 

hes  $list_. acl 

hes_$list.. dir_acl 
hes_$list_ dir_ lacl 

hes $list_ inacl 
hes_$quota_move 
hes_$replace_acl 
hes_$replace_dir_acl 
hes_$replace_dir_inacl 
hes_$replace_inacl 
hes_$set_copysw 
hes_$set_dir “ring brackets 
hes_$set_max_length 
hes_$status_ 
hes_$status_long 
hphes_$add_acl_entries: 
hphes_$add_dir_acl_entries 
hphes_$delete_acl_entries 
hphes_$delete_dir_acl_ entries. 
hphes_$replace_acl 
hphes_$replace_dir_acl 
hphes_$set_act 
hphes_$set_auth 
hphes_$set_be_auth 
hphes_$set_dates 
hphes_$set_dir_ring_ brackets 
hphes_$set_ring_brackets 
hphes_$status_backup_info 
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hes_$append_ branch 

hes, $append, branchx. 

hes $append_ Link. 

hes. —gavota get 

hes_$star_ 

hes $star_ list_ : 

hphes _.$quota_ reload 
n¢S_Squota_set | 

hphes_gsalvage_ dir 

hphés_$star_no_ acc ck 
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We have-claimed that the address space mahager we 
designed is simple, small and easy to certify. To substantiate 
this claim, we are including in this appendix the source code of 
our address Space manager for the reader's perusal. These 
programs differ from the actual programs that ran in our trial 


Multics system only in a few minor details. (1) 


We will divide this appendix into three sections. The 
first section contains a declaration for the KST. This 
declaration is used by programs that contain a "Zinelude kst;" 
statement. The second section contains the PL/I source programs 
that constitute the address space manager. Finally, the third 
section describes the calling mequende and functionality of 


system modules called by the programs presented in section two. 


The baseno and ptr PL/I builtin functions used in the 
programs in this appendix are non-standard PL/I functions used in 
Multics to manipulate pointers. A Multics pointer may be viewed 
as a pair of integer values. The first component of a pointer is 
interpreted as a segment number by the Mill ties hardware. The 
second component of a pointer is interpreted as a word offset 


within the segment specified by the first component. The baseno 


(1) See appendix I. 
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builtin function constructs a pointer to the first word in a 
segment given a segment number for that segment. The ptr builtin 
function constructs a pointer from the segment number in its 
first argument, which must be a pointer, and the integer offset 


which is its second argument. 
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/* BEGIN INCLUDE FILE - - - kst.incl.pli - - ~ #/ 


del kst_seg$ ext; 


del 1 kst aligned based (addr (kst_seg$)), 


lowseg fixed bin 
2 highseg fixed bin, 


fp, bp) bit (18) unaligned, 
2 aig hash PP} ot 127) = 

(Pp, bp) bit (18) unali 
2 entry (lowseg:highseg) like orice 


del kstep ptr; 
del 1 kste based (kstep) aligned, 


2 fp bit (18), 
2 “bp bit fa? 


segno fixed bin (17), 
rings bit (8), 

hdr fixed bin’ (3), 
dirsw bit (1 


“unused: BEE: (53; 
infcount fixed "bin (17), 


entryp ptey: un aligned, . 
id bit: (36) “eEtgneds 


RB NM NMNNAND ff 


/* END INCEUDE FILE - Stns kat’ Tinel. Par --- 4/ 


kst segment */ 


KST header declaration */ 

lowest segment number described by kst */ 
highest ‘Say pa number described by kst #/ 
free list 


uid hash table *%/ 


pointer to entry */ 
KST entry declaration */ 


forward rel pointer */ 
backward rel pointer #/ 


segment number of kste *#/ 


rings in which this segment is known 8/ . 
hi st or reoteure ang 7 

Gireatery yBS switch */ 

unused bits 

is asad ‘Sognent count #/ 


| ptt to ‘dir ‘entry #/ 


unique identifier #/ 


“OLL~ 


initialize _kst: 
proc Clowseg, highseg); 


/* 
initialize kst is called during process initialization to build a virgin 
USAGE: calI initialize kst (lowseg, highseg); 


lowseg fixed bin aie - - ~ lowest segment number described by kst 
highseg fixed bin (17) - - - highest segment number described by kst 


&/ . 
‘del (lowseg, highseg, 1) fixed bin (17) 
threed$in ext Srery (ptr, ptr); 


% include kat; 


kst 


initiate_: proc (a_psegno, a_ename, a_dirsw, a_link, a_segno, a_code) ; 


/# 
---> initiate_ is the ring zero gate which allows an object to be mapped 
into a process” address space. This module ony validates its caller s 
Les ht to initiate the object in question. If the request is valid then 
known. is called to actually map the object into the process address space. 
us Br call’ ‘initiate _(psegno, ename, dirsw, link, segno, code); 


gno. fi gf P1A7) -<- segment number of parent directory (input) 
‘ode. name. of .en ery t in directory i: ansveate’ nput t) 
free pat rien set if ‘entry is a directory (input) 
En UITE Coe secmant meabar OF. tarus€ (outiat) 
~-- segmen er arget (outpu 
tints J se status code (output) © 


possiblé gtatis béde values: isa — eee 

error _t&hin Suegkjow---- lor directory) already known to process 
error tahte in. ivaae iompmnt (9 access to return an information 
error CH ari: gt: -~-— no more room in known segment table 

erfor_ts iro entry. --- entry does not exist 

er 493 Le Ae pal TK ane is a link 


Or Size lidsex 6 aa invalid parent segment number 
error ta notadir --- parent is not a “Sear th 
able 9 Rt FPe:: ae Serans, saneas oe of the rong type / 


wee. ue b 


be bey ta dn: a, ante ("0"), 
awed: bs At Stat static, inte’ Ap 
segment, +7 fe: tie" init ts). 
ink. itery fi LE tate ye. 
del (error_| oinfo error. tabl se known, error _table $nrmkst, error_table_$no_ent 
error rote par tT eam fable_ge the et a error _| tebie link, -$ na 
error_table $wrong type) ext fixed” bin (35); 
del ot ,_braneh. {aro ener (fixed bin $173 char (32) aligned, fixed bin (17), bit (36) aligned, 


a4 ees “eda se za ont fey te tee bin (17)) t ( 
nu e returns 
rallgat noah ex eatry ext mit ag 


Zinclude kst; 
/*# - 


(36) aligned, bit (1), fixed tn (17), bit (1), fixed bin (35)); 


“re@bi- 


#/ 


psegno = a_psegno; /* copy input arguments */ 
dirsw. a dirsw; : , /* so our caller cant. change them */ 


tater ; acehame! 13*Ehee call a 


p 
if kstep = null T) then call return_code (error_table $invalidsegno); 
if “kste.dirsw then call return code (error_table_$notadir); 
if kste. ao = phoney_uid 
then if dirsw 
~~ then call MKN (baseptr ores Bae ails: “accessible); 


1 ace eall return_ code Nees table. $noinfo 
else 
opli gpkbranch info egne, ename, type, uid, ep, link, code); 
‘then @ = error. tab. ae nfo 


ptr (ps seessbobey ye uid, *sooeanible)? 


eee tie 
ey uid, access 


else ate we code: "teod e}; 


Fieve Link; 
“return. code ‘(error table _$link); 


ty 
Gn -segment) & dirsw | (type = dteegeory? & “dirsw 
e es 


1 return_code (error_table_ $wron typ 
p ake: 7A LL MEN ep, vid, accessible). = 


ed 
epi : 
craggy AOR: BAG, dirsw,. segno, acoeseibit, code); 
ea prea ode (ended; 
f ee Bin CEE 


a code ='c 
s to wee atla ox caller; 


end re 
return. to leas return: 


end initiate_; 
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makeknown_; 


/* 


a 6 


proc (ep, entry_uid, dir 


Sw, segno, accessible, code); 


---> makeknown_ maps a segment or directory (specified by dirsw) into its 
caller s address space. This module assumes that the process right to 


initiate the segment speci 
assumes that its input a 
This assumption requires 
to makeknown_ are not a 
USAGE: call makeknown_ (ep 


SEP ig ofEUSES alti 

entry_u a e 

dirsv bit (1) --- set ff ob 
o fixed bin(17) --- se 


accessible pit) ) --- set 
code fixed bin(35) --- sta 


del ep: 


del ring fix ee 7€ sen 


/# 


dirsw bit 
segno fixed bin: ¢17), 


acces epee ee ji 


t 
ks 


fied has already been established. It further 
uments will not be modified while it is executing. 
ts callers to be sure that arguments passed 
ssible to outer ring procedures. 

» entry_uid, dirsw, segno, accessible, code); 


object “s branch (input) 
--~ unique identifier of the object (input) 
ject is a directory (input) 
nt number bound to the object (output) 
f process has access to the object or its parent 
tus code (output) 


entry:aid’ bit (36)aligned, 


(input ) 


petite ERE eccera agg S 


Sh ee: 


otthbio 


*/ 


calf i eeren tee QO); 
kstsrch entry uid, accessible, hashp, kstep); 


f kstep = nul 


then d do; /* object already has a detectable KSTE */ 


code = error_table_$segknown; 
segno = kste.segno; 


end; ; 
else do; /* must allocate a new KSTE *#/ 
ifr rememaause then code = error_table_$noinfo; 
ogil kates peperre (= (segno, kstep, code); 
c 
xe sh ast, y kote); /* thread KSTE into hash class */ 
Pep = nu 


/*® increment parent’s inferior count #/ 


do 
Sid = See iehe (tized d (baseno (ep), 1 Runes: 


a = dirsw; /* fill in KSTE #/ 

dente: © 05 ; 

kate vetr ryp = ep; 

Aste. ids entry. uid; 

te dicate rings, ring+1, 1) = "1"b; /* mark kste as known in proper ring */ 
then do ie (ring > kste.hdr); /* update hdr of superiors #/ 


‘kate. ring; 
teks e.entryp = null {? . 
then kstep = get_kstep (fixed (baseno (kste.entryp), 17)); 
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terminate_: proc (a_segno, a_code); 
/* 


---> terminate_ is the gate into ring zero which allows a process to unbind 
a segment number from the object to which it was bound. If the KSTE has no 
inferiors and the segment number is not in use by other rings then the 
ps glib number is physically disconnected from tne object to which it was bound 
he segment number is returned to the free or reserved pool as specified 
by the reserved switch argument. If these conditions do not obtain t en the 
segment number is not disconnected. The KSTE is merely marked as no 
r in use in the caller's protection ring. 
OSA E: call terminate_ (segno, code) 


o fixed bin(17) - - - segment number of the segment 
e fixed bin (323 - - ~ error code (output) 


possible status code values: 


error_table_: invalidsegno --- segment, number is not bound to an object 
error_table_$infcnt_non zero --- can t terminate due to active inferiors 


error_tabte_gknown_In_other_rings --- can t terminate due to segment number being used in other rings 
“WPS ; 
del a_se > fixed ‘ba ‘bin a 


ee bin werSi returns (ptr), 


se Pan: 41): neturee: (ote, : 


seen 


del (error n e at Ss error table Sintont non zero) ext fixed bin (35); 
del error 4 ste nem noth ct f3 2508 n.T35)5. ; a 
del (baseno, fixed, null, substr)- buiitin; eres Las 

% include kst; 


a_code e fFixed bin 


del 


/* 
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#/ 


- /* copy values of input arguments #/ 
segno = a ites /* so our caller can iocke them #/ 
ks is “Tr te segno$inuse (segno); /* make sure call is legal 
ste 
then call ab abort error _table_$invalidsegno) ; 
ring = level$ge 
substr tkgte . “rings ’ ring+1, 1) = "OD; /* make unknown in this ring */ 
if kste.r nny 


igeee veoh carrer table_$known_in_other_rings); /# can’t terminate in another ring */ 
unt 
. gbort , -fernor rtp oe zero); /# ean “t terminate if infcount non zero #/ 


a (ta 4 (has ees Rl decr arewens events inferior count ®/ 
€) xe eno -> kste.en ; 
Rest aes (pageno (kstep <> kate, ns aa 


/* deposit kste in free pool */ 


kstsrch: proc (uid, accessible, hashp, kstep); 


/* 


*/ 


-iil= 


to the desired and the hash class thread word. Only if the process has established 
its righ o detect the existence of the object bound to the KSTE will a match be found. 
The conditions requires for kstsrch to return a given ect tas number are 
1) the segment er must be bound to the correct object (as identified by uid), 
2) the segment number must be detectable in the caller s ri ng, and 
3) no higher fusbeha oan may have the segment number initiated. At the expense of assigning multiple 
Segment {nisi ject, when not necessary for protection: ‘reasons, ksterch. co 

a weaker ma hm such as matching only if the caller has access to . the target 


obj ect She vi target object. 

USAGE: ais Bere cha accessible, Jeashp, _ketep); 

uid bit(36) aligned ---- uni ue as of object searched for (input) 

pcosse’> e bit’ RF wme- get process has any access to the object or its parent (input) 


hashp ptr --~-- pointer to the Beek whiter thread word (output) 
kstep ptr -~-~ PoLprer: to the desired KSTE if found else null (output) 


---> MeSTR a searches the KST unique identifier hash table and returns pointers 


del uid bit (36) al 


ing, nae ene (3), 


(a Pere mull; mod, dimension) builtin, 
ret ig qxt entry () returns (fixed bin (3)); 


eerie mel 


* ies Scar! cx uid_hash (mod (fixed (uid), dimension (kst.uid_hash, 1)))); 


og ths: (kete.fp 
_ Retep = ptr (catep, kite. fp); 
oi match | ( then re retura; et - 


= null OF 


match: 3 hs ay returns (bit | - . : 
oe if. reuur kste. id « U Uscsasibic | kste.hdr >= ring) 


then qa 
th abcexaibie (kst hd ing); 
en max (kste.hdr, r 
‘else hdr = kste.hdr; oa 
if substr (kste. rings, hdr + 2, 7 - Ber) = "0"b then return ("1"b); 


end; 
return ("0"b); 
end match; 
end kstsrch; 


kste: proce (); 
/* 


---> kste$reserve extracts a kste from the free list 
USAGE: call kste$reserve (segno,kstep, code) ; 


kste provides the functions of freeing and reserving segment numbers 


~--> kste$free frees a segment cer peiten a kst entry pointer 


The kste is threaded onto the free 1 
USAGE: call kste$free | kstep); 


no fixed bin (17) - - - ‘segment number (output) 


gm 
r= - = pointer to the kstep (input/ovtput) 
code’ fixed bin (385 - = - error ode Coat Sut § i 


del code fixed bin (38) 
(segno, save_segnod fixed bin (17) ; 


del thread$in ext entry (ptr, ptr), 
thread$out ext entry ptr) 5 


del (addr, ptr, unspec) ‘builtin; 
del error_table_$nrmkst ext fixed bin (35); 
-$ inolude kst; 


qntry (se o, kste ogde); 
if kat free e_list. fp’s : 


‘then: *G6 
ae co = error, _table_$nrukst ; 
: _ Preturn; 


Kat z ben (aade lana kst.free_list.fp); 


reserve: 


return? 


entry (kstep); 
save_segno = kste. GBeEno; 
unspec | mate) se a eis 


kste .segno 
call thread$in- (adar elest free list), kstep); 
return; 


free: 


end kste; 


/* terminate chains a/ 
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get_kstep: proc (segno) returns (ptr); 


/* 
get_kstep translates a segment number into a pointer to the associated 


---> 
USAGE: kstep = get_kstep (segno); 
“pene number 
T 


segno fixed bin(17) ---- the s 
2) kstep ptr ~--- pointer to a KS 


*/ 
% include kst; 


del segno fixed bin (17), 


(null, addr) builtin; 
if segno < kst.lowseg | segno > kst.highseg 


then return (null ()); 
return (addr (kst.entry (segno))); 


end get_kstep; 


KSTE 
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validate_segno; 
proe (); 


/* 
validate_segno provides generally useful kste validation functions 
Each entry returns a pointer to the associated kste if a particular conditions holds. 
If the stated condition dees not obtain then the null pointer is returned. 


---> validate. _Segno$free checks to see aoe the segment number is free 
USAGE: kstep = validate_segno$free (segno 


2e-> validate _.Segno inuse checks to that the segment number is bound to an object 
USAGE: kstep = validate_segno$inuse (segno); 


cote fixed bin (17) = - - sogment number (input) 
kstep ptr - ~~ pointer to. the kstep (output ) 


#/ 
del segno, fixed bin (17); 
del get_kstep ext. entry (fixed ‘bin al Feruras ieee 
del (null, unspec) builtin; 


Sinclude kst; 


gage ( ey eee 
“ ae ORE cits all 


i | + gat tr); 

FTP ae bate (etal POMRYY; ot 
Ir ees . rekciie - se 

del ae: bie i ¥ neg ‘eAr) 


0); 
t 1 turn 
if PBs Chetan pa "0O"b) then return (null ()); 


free: 


end patie genes: 
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kste_info: proc (segno, uid, branchp, code); 


/# 
---> kste_info returns the uid of the pee bound to a segment number 
= well as the address of the object s branch. This information is: used 

to lock the paren: Girect ory . and focate ‘the desired branch. 
USAGE: call Este _Anfo (segno, uid, branchp, code) ; 


--~> kste_info$update_| brarich: offset is called by the file ayaten. when it notices that 
the online salvager has Soved an entry in a directory. 

It updates the pointer in the kste to reflect the new location of 

of the branch within the directory. 

USAGE: call kate_infogupgate,, branch _oftset. “(segno, branch_offset); 


bin (17) ---- 4 numberof the ebject (1 as ot 
aid bat 36) aligned ---»= gn} ue (ident Ler of the object output) _ 


branchp ptr <--- br rer (out 
branch P Ptset bit ios aligned -~-~ ra Sof branch of opgect: in Parent (output) 
a / : 


code fixed bin(35) ---— 8 atus code 
del o fixed bin (1 5. ms 
code fi fixed bin (388 7 
ranch 


branch’ ) ts t bit (18) a ip ed 

uid bit £585 aligned; a ai 
del (error_table_$invalid o,.-error table: enter ext fixed bin (35); | 
del validate. ble finy alideegnc ‘satry eae‘ (17) returns goin % 


_$include kst; 3 one 


kat = validat 1 (sqgn0) 
if katep = saate geenct ad 


i. . error: table Sinvali doce; s ie 
- return; 


end; ae 
uid’s kste.id; 
if kste.entryp = mull 0 


then do; 3 
code = error table _dnoentrys 
= return; 
branchp = kste. entr 
code = 0; ka 


ica 


Ce we 


return 
update_branch_. voftset: 
entry (segno, b arch: offset); = 
ket entry (segno sentryp = ptr (iat entry disegncds entryp, branch_offset ); 


end uate into; 


---=> get_branch_info 


This file system routine is called by initiate_ to get 
the attributes of a named entry in a. directory. If the caller 
has no access to the named object (if it exists) or to the parent 
directory then the status code error_table_$noinfo is returned. 
The reader should note that get_branch_info must read the access 
control list of the directory containing the named entry if the 
entry does not exist. or if the process has no. access to the 
entry. To locate the access control list of the containing 
directory, get_branch_info must call the kste_info module of the 
address space manager, a recursive invocation of the address 
space manager. 

Usage: call get_branch_info (psegno, ename, type, uid, ep, link, 
code); 
psegno fixed bin (17) ~-- directory segment number (anit) 
ename char (32) aligned --- name of entry in directory (input) 
type fixed bin (17) --= type of the object: (output) 

0 -= no entry 

1 -- segment 

2 -- directory 

= 3 == link 
uid bit (36) aligned --- unique identifier of object. “Ceatpne) 
ep pointer --- pointer to the entry of. the: 06 Jec: (output) 


link char(*) varying ~-- contents of the: ‘Link (output) 
code fixed bin 35) a8 error code foutput): : 
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---> thread$in 


This routine adds an element to a two way linked list 
of elements. The first word ‘of each element contains the 


necessary forward and backward pointers. 


Usage: call thread$in (where, what); 
where pointer --- pointer to an element in the list after which 
the new element is to be threaded... . 


what pointer --- pointer to the element’ to “be threaded into 
the list. 


---> threadgout 


This routine threads an element out of a two way linked 


list built by thread$in. 


Usage: call threadgout (what); 


what pointer --- pointer to the element to be threaded out of 
the list. 


~--> level$get 


This routine returns the validation level of the 
Calling procedure. In all cases considered in this thesis the 
validation level of a process is equal to the number of the ring 


in which the process was executing when it called into ring zero. 


Usage: ring = level$get (); 


ring fixed bin (3) --- validation level of the process. 
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---> disconnect 


This routine physically removes a segment number from a 
process! address space by zeroing the segment descriptor word for 
that segment number in the process! virtual address translation 


table. 


Usage: call disconnect (segno); 


segno fixed bin (17) --~- segment number to be disconnected. 


vias 


In our discussion of the Multics address space manager 
we omitted three mechanisms that it... currently supports. These 
mechanisms, which are non-essential to our design, were omitted 
to simplify our presentation ‘and avoid confusion. In this 
appendix we will briefly describe these mechanisms and show how 


they fit into our design. 


I.1 Reserved Switch 


The Multics initiation and termination primitives take 
a reserved switch argument. In the case of initiation, this 
switch specifies, if set, that the caller wishes to specify what 
segment number to bind to the object when it is initiated. 
Naturally, ring zero must check that the caller has in fact 
reserved the segment number. When the ring zero initiation 
primitive is called without the reserved switch. set, then ring 
zero chooses a segment number from a list it maintains of free 
segment numbers. This segment number is: bound to the object and 
returned to the caller. In the case.of termination, the reserved 
switch specifies whether the freed. segment. number is to be 


eligible for assignment when a free: segment.number is needed. 
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The reserved switch must clearly remain a protected 
security kernel mechanism in our new address space manager. Were 
this not the case, one protection domain could cause another 
protection domain to malfunction by using a segment number’ that 


the first protection domain had reserved. 


I.2 Copy Switch 


During the process of initiating a segment, an 
attribute in its directory entry called a copy switch is 
examined. If the segment has the copy attribute, then a copy of 
the segment is made and this copy is made accessible to the 


process instead of the original. 


We can use the mechanism of reflecting information out 
to an outer ring by setting a status code to remove copy switch 
processing from ring zero. This is possible since the current 
initiation primitive takes an argument that allows a process to 
bypass copy switch processing. Together with the fact that no 
ring zero sneaudunes or data bases have their copy switch set, 
this insures that the protection mechanisms of the system do not 
depend upon the segment copy on initiation facility. To take 
advantage of this, our new initiate primitive will not process 
the copy switch. ‘Instead, it will always initiate the target 
segment and return a status flag indicating whether or not the 


Segment's copy switch was set. The outer rings can then worry 
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about creating a copy of the segment, terminating the original, 
and returning the segment number of the copy if the copy switch 
was set. This allows the concept: of @ copy awitch to move out of 


ring zero. 
I.3 Transparency Switches 


When an segment “is initiated in the current Multics. 
system, the address space manager sets. two. switches,” called the 
transparent usage switeh and the transparent modification switch, 
in its KSTE. These switches determine whether this process' 
usage and modification of the segment - is to= be detectable to 
other processes in the system. These vEanepenency switches have 
no influence upon our design’ except that ‘in an. implementation of 
our design (as in our test captenantetton) these switches would 
be kept in the KSTE of a segment ‘and the eddriesa:: space manager 
would retain the two lines of code fron ‘the cenrert address space > 


manager that sets these switohes.. 
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